THE BRYCE IS RIGHT!

Software for the finest computer – The Mind

  • Tim’s YouTube Channel

  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 967 other followers

  • Categories

  • Fan Page

  • Since 1971:
    "Software for the finest computer - The Mind"

    Follow me on Twitter: @timbryce

  • Subscribe

Archive for the ‘Project Management’ Category

ESTIMATING – GETTING IT RIGHT

Posted by Tim Bryce on February 20, 2017

BRYCE ON PROJECT MANAGEMENT

– No Virginia, there is no magic in producing a project estimate.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I’ve long given up looking for panaceas. Actually, I have always regarded estimating as a relatively simple task and have taken my queue from the construction industry who has had to frequently produce reliable estimates over the years. As such, there are basically three variables involved:

* Methodology – defines the stages of work by which projects are completed, from beginning to end. Some portions of the project will be executed serially, others in parallel, either way, each stage should define precisely what work has to be accomplished to the types of components involved. Typically, components are identified, designed, tested, and installed in moderation which is commonly referred to as “stepwise refinement” (going from the general to the specific) as prescribed by the methodology.

* The components involved – in the construction field, it is the wood, stone, glass, nails, rivets, steel beams, etc. to be used to construct a building. In the I.T. field it is the data elements, records, files, input, outputs, programs, business processes, etc. The methodology dictates the sequence by which the components are implemented. A component assembled at the wrong time and place will likely prove disastrous, which is why the methodology is so important. To make this work, it is necessary to produce a rough design of the object in question. For construction, it would mean a complete rough design of a building, aka, “artist rendering.” In I.T., it would mean a complete rough design of a system or program. Only after the rough design has been completed can a listing of the components be identified.

Another consideration is the state of the components, how many are new versus how many can be reused from other projects. To illustrate, if there are already preexisting nuts and bolts to satisfy the product, they certainly can be reused; if not, new nuts and bolts have to be designed. Within a systems development project, if a data element such as “Customer Number” has already been invented and implemented, there is no point in introducing a redundant component; developers should simply reuse the existing data element. Such reusability of components not only expedites development time, but promotes integration of different products.

“Bill of Material Processors” (BOMP) are commonly used to keep track of components, be it in the construction field or I.T.

* The skill of the people charged with executing the project. A novice worker will obviously take longer to perform a given task than an experienced expert. This is also why it is preferable to have the people charged with the work participate in the estimating process as it becomes a reflection of their commitment. In a situation where project personnel are unknown, the Project Manager can still render an estimate based on “averages” defining the amount of time necessary to build a component for a given task. As projects are executed, the actual time expended to complete a component for a specific task should be captured so such averages can be refined based on historical data.

This approach to estimating is universally applicable to any product development based project. It is based on the recognition that most estimating errors are errors of omission, not commission. It is the forgotten or overlooked components that lead to most estimating errors. Again, this is why the rough design is so vital as it will overcome the problem of omissions. As in any construction project, a rough architectural design is required to effectively estimate the project to build it. The same is true in I.T. projects where the objective is to build a new system. To do so, a complete rough design of the system must first be prepared to effectively estimate the remainder of the project.

This approach also distinguishes the use of time as either “direct” or “indirect.” Whereas direct time represents whole work, indirect time represents interferences detracting from project execution. Estimates should be expressed in direct time, not indirect time, as we want to know the amount of pure effort needed to complete a component and task. This approach to time also implies estimating and scheduling are separate activities. Whereas, direct time is used to express estimates, indirect time is used to calculate schedules. For example, if an estimate for a project task is ten direct hours, and a worker is only able to spend four direct hours of work each day (with another four indirect hours spent elsewhere during the day), the task should be completed in 2.5 working days. Separating time into “direct” and “indirect” greatly improves precision in both estimates and schedules.

Here is a typical scenario for estimating a product related project, be it construction, I.T., manufacturing related, or whatever:

1. Specify and analyze requirements.

2. Prepare a rough design of a product to satisfy the requirements.

3. Prepare an itemized listing of components to be used in the product, aka, “Bill of Materials,” identifying which are new and which can be reused.

4. Based on the materials, define the remaining stages of work to develop the product (the methodology).

5. Estimate the amount of time necessary to complete the various stages. If project personnel are known, have them participate in the estimating process.

6. After the estimate has been defined, calculate the project schedule based on the methodology and use of time (direct vs. indirect).

7. Review with the client for approval.

This approach is certainly not new and has been used for many years in a variety of industries. Ultimately it represents a complete mental execution of the project in order to determine costs. This is essentially no different than what a professional golfer does before swinging his club on a drive; he visualizes everything from how he is to swing the club, the follow through, to where he wants the ball to land, and the ensuing strokes necessary to complete the hole. Preparing a rough design is no different. It is thinking the project through to completion by considering all of the components needed to satisfy the product. Will it be perfect? No, but it will be more accurate than making wild guesses based on some wild pseudoscientific calculation. The only drawback to it though is it requires some hard work in upfront planning and design; it is certainly not a panacea, but then again, there never has been any magic in estimating that I know of.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 40 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:   timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2017 by Tim Bryce. All rights reserved.

Also read Tim’s columns in the THE HUFFINGTON POST

NEXT UP:  IT IS TIME FOR THE REPUBLICANS TO FLEX THEIR MUSCLES – No more excuses; let’s roll!

LAST TIME:  MY TRIP TO THE GYM  – Things have changed over the years.

Listen to Tim on News Talk Florida (WWBA 820 AM), WZIG-FM (104.1) in Palm Harbor,FL; KIT-AM (1280) in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube. Click for TIM’S LIBRARY OF AUDIO CLIPS.

 

Advertisements

Posted in Business, Management, Project Management | Tagged: , , , , , | 2 Comments »

BOM PROJECT ESTIMATING

Posted by Tim Bryce on March 30, 2015

BRYCE ON PROJECT MANAGEMENT

– If Bill of Materials is good enough for engineering and architecture, why not systems and programming?

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

Estimating is one of the most controversial subjects in project management. There are some people who have turned the subject into a cryptic science involving esoteric techniques.

Estimating is simply the process used to determine the amount of effort and cost required to implement a project, in part or in full. It is important to acknowledge that estimating is fundamentally an effort at projecting the future. Like all projections, the more facts and information available, the better the estimate. There is a natural human tendency to avoid making estimates because estimates represent commitments, and people tend to shy away from commitments, particularly when they are not sure of the facts. Nevertheless, little progress would be made if we never attempted to plan for the future.

Most estimating errors are errors of omission, not commission. It is what we forget to estimate that often leads to problems. Methodologies, with their defined structure, materially assists with eliminating some of the unknowns when estimating. They provide frameworks and structures acting as checklists for estimating. Methodologies isolate the activities to be performed into small enough increments, thereby minimizing the margin of error.

An estimate improves in accuracy in direct relation to the level of detail considered. A methodology defines the sequence of events by which parts are assembled. For example, a construction methodology identifies all of the resources of a product, such as lumber, steel, glass, etc. and how they are assembled. An Information Systems related methodology, such as “PRIDE”-ISEM, specifies the sequence by which data elements, records, files, inputs, outputs, processes, etc. are assembled. This provides the ability to use a “bill of materials” (BOM) technique to count all of the resources in the product and develop an estimate for the project, in part or in full, based on the standards developed for completing and/or installing a resource. This is why “PRIDE” methodologies put an emphasis on “rough designs” in the early phases of work.

To better understand the BOM concept, consider all products are composed of a variety of parts, be it electronics, automobiles, airplanes, ships, bridges, skyscrapers, homes, etc. Using BOM, the various components are identified and related to the other parts they will be attached. To illustrate, here is a lawn mower showing all of the parts, identified by number and name, along with their relationships:

Such illustrations can typically be found in most product warranty guides. Obviously, BOM is an old concept used by engineers and architects for many years, but they can also be applied to information systems involving sub-systems (business processes), procedures (both administrative and computer), programs, files, inputs, outputs, records, and data elements. It can also be used in programming components, such as modules. To think of systems in this manner is somewhat of a revolutionary concept.

From such designs, the Project Manager is asked to consider:

* The number and types of NEW components to be created.
* The number and type of existing components requiring MODIFICATION.
* The number and type of existing components that can be RE-USED as is (no modification required).

To illustrate, in a “PRIDE”-ISEM Project (Phase 1), a complete “rough design” of the envisioned system is produced in Activity F. In Activity G, the Project Manager takes the rough design and makes the following type of assessment:

COMPONENTS NEW MODIFY RE-USE
SYSTEM 1
SUB-SYSTEMS 14
ADMIN PROC 23
COMP PROC 13
PROGRAMS 28
MODULES 33 10 112
INPUTS 17 5
OUTPUTS 37 13
FILES 56 5 43
RECORDS 250 50 306
DATA ELEMENTS 60 257

This analysis is essentially no different than other products consisting of different components, such as circuit boards, chips, nails, screws, lumber, girders, glass, gaskets, pistons, etc.

In systems, the rough design is used as the road map for the project (in the above example, there will have to be 14 Phases 3-7 because there are 14 sub-systems and 13 Phase 4-II & 6 for the 13 computer procedures, and at least 28 Phase 5’s for the programs). It is also the basis for the project estimate. Such estimating is greatly facilitated through the use of an IRM Repository which controls the components and, as such, acts like a Bill of Materials Processor (BOMP).

The BOM concept permits the establishment and application of estimating guidelines. To illustrate; how much direct time does it take to weld a six inch pipe? Define a data element? Design a sub-system? Such standards should be based on whole work (Direct Time) as opposed to including interferences (Indirect Time). Indirect time is a part of the work environment and can vary from company to company, group to group, even person to person. Estimating, therefore, must be accomplished using Direct hours only.

Having standards in place, we can then consider variations based on the skills of the worker. For example, how long it takes a novice worker to weld a product will certainly be longer than an expert. The same is true in systems analysis and programming. This is where a Skills Inventory comes in handy to select the appropriate worker for a project assignment.

By making system designers build a rough design of the product early in a project, the bill of materials can be populated accordingly and greatly improve estimating accuracy. As the project progresses, and changes are identified in the product structure, revisions in estimates can be easily made.

This is all made possible by using an engineering/manufacturing approach in the design and development of products, including systems.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:  timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  44 YEARS OF “PRIDE” – and the lessons we have learned.

LAST TIME:  YOU’RE FROM WHERE?  – America is a country separated by a common language.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.

Posted in Project Management | Tagged: , , , , | 2 Comments »

PROJECT MANAGEMENT INTEGRATION

Posted by Tim Bryce on March 23, 2015

BRYCE ON MANAGEMENT

– Success resides in taking an integrated approach, not piecemeal.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

About ten years ago I wrote a paper titled, “Why Project Management Fails.” In it, I contended one of the reasons for failure was because of a “lack of consideration for the magnitude and complexities of project management and attack it in piecemeal.” Frankly, nothing has changed over the last ten years to lead me to believe this has changed.

There are five basic activities in Project Management: Planning, Estimating, Scheduling, Reporting, and Control. These activities work best when they are applied in an integrated manner, not separately. Let me illustrate:

* Project Planning involves such things as defining Work Breakdown Structures (WBS) and precedent relationships (methodology). This becomes the bedrock of all other project activities. However, planning also includes the application of human resources to project assignments. To do so, a Project Manager needs to consider what human resources are available, their skills and proficiencies (Skills Inventory), and their work schedules (Resource Allocation).

* Project estimating is an expression of the amount of time necessary to complete a project task. It is also used to calculate costs and project schedules. Ultimately, estimates represent personal commitments by workers to project assignments. Of course, we cannot calculate an estimate without the WBS as defined in project planning.

* Project scheduling is a projection of start and end dates of project tasks, and is calculated from worker estimates, their work schedule, and work environment (an effectiveness rate which considers interferences). This also requires the WBS and precedent relationships as defined in Project Planning.

* Project reporting – workers must routinely report their progress by reporting the amount of time spent on project assignments during a given period (usually weekly), along with the amount of time remaining on each task. Over runs and under runs against estimates cause a chain reaction in project schedules. Again, this requires the WBS and precedent relationships as defined in Project Planning. For example, if a project task is completed early, the ensuing tasks can start early. Conversely, if a project task is completed late, the ensuing tasks will be delayed. Project reporting also analyzes the amount of time expended, its cost, which is normally billed to a user area. Time reporting includes Direct Time (work on project assignments), Indirect Time (interferences), and Unavailable Time (e.g., vacations, holidays, time off). The reporting of Indirect Time and Unavailable Time is useful for calculating realistic schedules and managing the worker’s work environment. Capturing time in this manner has the added benefit of developing standards for estimates.

* Project control – without the other activities, project control is impossible. It studies estimates versus actuals, schedules versus actuals, the amount of time and costs expended versus time and costs remaining. Tolerance rates are used to detect when estimates and schedules have slipped to the point it is necessary to take corrective action (e.g., replace people) and recalculate estimates and schedules.

Each project activity is important in its own way, yet synergy results when all five activities work in concert using an integrated approach. When executed autonomously, inconsistencies and discrepancies ensue. For example…

– Developing a project plan that estimators and schedulers will ignore serves no purpose.

– Developing a project estimate that cannot be used to drive project schedules is a futile gesture.

– Developing a project schedule that fails to recognize Indirect and Unavailable Times (nor is tied to resource allocation) is useless.

– Reporting time without applying it to project estimates and schedules does not permit project control.

– Project control is impossible without a road map (methodology), estimate or schedule.

To succeed, it is necessary to remember Project Management is a philosophy of management, not an elaborate set of tools and techniques. I will not deny there are some fine software tools out there, but unless they can be seamlessly integrated into all of your project management activities, it will be counterproductive.

The lesson is simple: do not attack Project management in piecemeal, take a comprehensive approach. You will have a better chance for success and produce superior results.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:  timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  AT THE BREAKING POINT – Ramblings regarding the ideological divide in this country.

LAST TIME:  WORLD WAR III?  – Has it already started?

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management | Tagged: , , , , | 2 Comments »

METHODOLOGY DESIGN 101

Posted by Tim Bryce on March 9, 2015

BRYCE ON PROJECT MANAGEMENT

– “If you don’t know where you are going, any road will take you there.”

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

When we introduced “PRIDE” as the first commercial methodology for system design in 1971 we never realized the impact it would ultimately have on the industry. It spawned several competitors, both commercially and academically, many of which were various interpretations of the classic “waterfall” approach as implemented by colleges and CPA firms. Today, many companies avoid the use of methodologies as they are considered bureaucratic paper mills. In some instances, this is true, but the fact remains, you cannot build anything of substance, be it a system or otherwise, without a methodology. The question then becomes, how to construct a methodology suitable for your company or a given project. To this end, I offer this tutorial on designing methodologies.

INTRODUCTION

If we lived in a perfect world, there would not be a need for managers. Everyone would know precisely what their assignments were and would successfully accomplish them on time and within budget. However, the reality is we live in an imperfect world. We as human beings make mistakes; we work on multiple assignments concurrently, and require guidance. It must be recognized from the outset that project management does not come free, nor does it come naturally to people.

Traditionally, the typical approach to project management has most often been to find a project manager, provide resources, and then give them an assignment with no direction as to how the project will be conducted or controlled. Under this approach, the success or failure of the project is dependent on the abilities and experience of the project manager and how well the manager can organize and train the project team, plan the project, estimate, etc. Consequently, there is significant trial and error in the process. This approach usually results in a unique method for the particular project because it reflects the thinking of the project manager. Different managers use different techniques and ideas. In other words, it is quite common for systems projects to lack uniformity and consistency, thereby workers have to learn the methodology with each new project assignment.

Another common approach used was the “brute-force approach.” Simply stated, “I don’t care how you get the job done; just have it completed by (date).” This approach shows a lack of sensitivity to the complexity of project management.

There is more to project management than maintaining costs and time schedules. It is the process of applying resources to a defined goal and attaining this goal within time and cost objectives. Fundamentally, it is a people oriented function as opposed to an administrative or clerical function. Project management, therefore, is not a tool or technique, but rather a philosophy of management.

Project management is to a methodology, what production control is to an assembly line. Without the assembly line, production control is a useless exercise. Conversely, without a methodology, project management is useless.

The ultimate test of a methodology is if it can operate independent of project management. The two are not synonymous. Although they work in concert, there are distinct differences. Whereas a methodology dictates what work is required, project management controls the application of work. Just as an assembly line can produce a product without production control, a methodology can produce a product without project management. Therefore, a methodology is independent of project management, but project management is totally dependent upon a methodology.


A project is an application of effort towards prescribed objectives through the execution of a defined sequence of events. All projects have a life cycle; a beginning for planning, a middle for execution, and an end for review. Each project has a unique scope, set of objectives and defined sequence of events. The methodology thereby is the “road map” for a project. It provides organization and direction.

For any methodology, there should be a conceptual foundation explaining the rationale for its structure. In the case of “PRIDE,” we introduced the concept that “a system is a product that can be engineered and manufactured like any other product.” This was a revolutionary idea at the time, and still is to many system developers today. Nevertheless, this concept allowed us to use a hierarchical product structure to decompose a system top-down, and test/install bottom-up. This permits us to design and build the various parts of a system in parallel and concurrently, just as engineering and architectural projects are conducted.

“PRIDE” was a departure from the conventional wisdom that systems were developed using a linear approach, such as that found in the “waterfall” approach.

WORK BREAKDOWN STRUCTURE (WBS)

In order to perform project planning, we must resolve the following questions:

1. What is the scope of the project? – The scope must state the project’s objectives and the parts of the organization involved, both directly and indirectly.

2. What are the steps required to meet the project’s objectives? Performing work in a logical sequence gives direction to the project. The inability to do so results in lost time and effort. Therefore, not only do the required steps in a project need to be defined, but the precedent relationships between work steps must also be defined.

3. What are the deliverables and benchmarks of the project? In order to verify a particular project task has been completed, it is necessary to substantiate that all aspects of the task has successfully been executed. An impartial and objective mechanism checking the completeness of tasks is necessary. It is important to demonstrate tangible results from our project efforts in the form of accomplishments and deliverables. Any task that does not result in a reviewable or tangible result is an unnecessary step that should be eliminated.

4. What resources are required to perform the work? Assigning the correct resources to the appropriate work steps is a critical factor in every project. By properly defining the work steps and the benchmarks, it is possible to clearly identify the skills required to execute the steps. Resources with the appropriate skills and availability can then be assigned to the project tasks.

A WORK BREAKDOWN STRUCTURE IS A HIERARCHY

All projects have a structure depending on the methodology used. The methodology defines what is going to be produced. It can be as simple as one step or as extensive as several phases involving multiple activities and tasks. The methodology represents the selected approach for implementing a project. It is structured into a hierarchy consisting of one or more phases of work. A phase represents a major “key event” or milestone in the project. Each phase consists of one or more activities representing “sub-events” required to meet the milestone. Each activity consists of one or more operational steps or tasks representing the individual actions to be taken in the project.

Each phase, activity and operation of a methodology should produce a reviewable result (work product) to substantiate completion of assignments. Otherwise, a methodology becomes a meaningless series of tasks. In systems development, such deliverables include such things as reports (e.g., Feasibility studies, design documents, program source code (and executables), data base structures, test data, test results, project audit, etc.). If the deliverable hasn’t been produced, we can conclude the work step wasn’t performed. If the deliverable was produced, there should be criteria to evaluate it, thereby providing a mechanism to review and correct if necessary.

Bottom-line, for each work step, we should define:

* What is its purpose?
* What will it produce (deliverable)?
* What is the criteria for substantiating completion?
* Who will perform the work (e.g., project functions assigned to the work step, such as analysts, programmers, managers, carpenters, architects, etc.).

The level of detail required to perform a project is ultimately left to the discretion of the Project Manager. If a simple project, perhaps the manager will only define a phase with a few activities. However, if a project is large and complex, the manager may wish to define and manage at the operation level.

PRECEDENT RELATIONSHIPS (DEPENDENCIES)

Up to this point we have only defined WHAT work is involved, not its sequencing. A methodology defines not only the various units of work, but also dependencies between the work steps. Such dependencies are referred to as “precedent relationships.”

Project worksteps may be conducted either sequentially or in parallel (alluding to “branching”). Precedent relationships define what worksteps precede and succeed a single work step.

Precedent relationships can be defined between work steps in the same level of the methodology structure. This means:

PROJECT-TO-PROJECT relationships.

PHASE-TO-PHASE relationships.

ACTIVITY-TO-ACTIVITY relationships.

OPERATION-TO-OPERATION relationships.

This brings up two points:

* Progression between project work steps at the same level cannot proceed until the subordinate levels are fulfilled. This means you cannot move from one project to another until all of the phases from the first project have been performed; nor can you move from one phase to another until all of the activities from the first phase have been performed; nor can you move from one activity to another until all of the operations from the first activity have been performed.

* You cannot define lower level work steps until you have first defined the higher levels. In other words, you must define phases before you define activities, before you define operations.

The one exception to this is a PHASE-TO-PROJECT relationship where a separate project can be activated pending completion of a phase. This can be demonstrated by separate “PRIDE”-ISEM (Systems Engineering) and “PRIDE”-DBEM (Data Base Engineering) projects:

NOTE: Although Project-to-Project and Phase-to-Project Relationships are permitted, they are uncommon. Most projects will only show inner dependencies (phase-to-phase, activity-to-activity, operation-to-operation).

Although “branching” (parallelism) can occur at any level in the methodology, the project manager will typically find less need for branching at the lower levels of the methodology structure. This means phases are more apt to branch than operations. Most operational steps within an activity are performed serially (sequentially).

To expedite the development of methodology structures, we have provided a “Methodology Definition Worksheet” which is used to define the Work Breakdown Structure and precedent relationships. To illustrate:

LEVEL-1: DECOMPOSING A METHODOLOGY INTO PHASES

METHODOLOGY CRITERIA

In order to effectively organize a project it is important to recognize the basic elements of a methodology:

Mandatory Requirements

1. A defined Work Breakdown Structure (WBS) – consisting of a series of work steps in various levels of abstraction (e.g., Phases, Activities, Operations).

2. Defines the project functions responsible for performing the various work steps.

3. Defines the project dependencies (the precedent relationships between work steps).

Without these mandatory requirements, a methodology is illegitimate and should be referred to as something else.

Optional Requirements

1. Have a single phase to initiate a project, and a single phase to conclude it. Multiple starts and multiple ends are not desirable from a management point of view.

2. The methodology structures should be based on reviewable work products to verify completeness. If the methodology is not defined accordingly, the “Dance of the Fairies” phenomenon occurs – this is where a series of meaningless work steps are defined with no verifiable end result.

3. The methodology structures should be reusable on multiple projects.

4. Provide for both sequential and parallel project execution.

5. The methodology structures should accommodate a product structure, thereby allowing parallel processing.

6. Although these latter requirements are not mandatory, they are highly desirable features and have been incorporated into the methodologies in “PRIDE”.

Project planning is made simpler by the existence of standard methodologies, such as “PRIDE,” which include defined phases, activities, deliverables, precedent relationships and the functions to perform the work. This saves time in project planning and brings consistency to projects of like kind.

Then again, system designers and programmers tend to resist the discipline of a methodology; as such, the old adage is true, “If you don’t know where you are going, any road will take you there.” However, it is inconceivable to build anything of substance without a methodology; it is how bridges and skyscrapers are built, automobiles, aircraft, consumer electronics, highways, even medical care and food service. Come to think of it, just about everything requires a methodology. So what makes system designers and programmers special?

For more information on the “PRIDE” Methodologies for IRM, see:
http://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/097861822X

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:  timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2015 by Tim Bryce. All rights reserved.

NEXT UP:  THE DICHOTOMY OF POLITICAL CORRECTNESS – If we cannot publicly discuss certain subjects, it seems perfectly reasonable the media shouldn’t either.

LAST TIME:  GREED AND IGNORANCE = TEMPTATION  – What the “Flim Flam Man” teaches us.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific). Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management | Tagged: , , , , | 8 Comments »

THE FALLACY OF MAN HOURS

Posted by Tim Bryce on November 14, 2014

BRYCE ON MANAGEMENT

– There is, of course, a better way.

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

I’ve never been comfortable with the concept of “Man Hours,” not that it’s a gender issue, but rather it implies ignorance of how time is used in the work place and fumbles away some simple management concepts needed to run any business, namely accountability and commitment. Actually, I thought the “Man Hour” concept disappeared with the passing of the 20th century, but it appears to be making a comeback.

The fallacy of the “Man Hour” concept is that it assumes a person is working productively 100% of the time. This, of course, is hardly the case in any company. Workers are either working on their assignments, be they what they may, or there are interferences keeping them from their work, such as meetings, phone calls, e-mails, reading, breaks, etc. Time spent on work assignments is referred to as “Direct,” and time spent on interferences is referred to as “Indirect.” The relationship of Direct to Indirect time is referred to as an “Effectiveness Rate” delineating the use of time during the work day. For example, in an office environment, 5.6 hours are typically spent on Direct work, and 2.4 hours are typically spent on Indirect interferences (assuming an eight hour business day), or an Effectiveness Rate of approximately 70%. In no way should Effectiveness Rate be confused as an efficiency rating; the two are NOT synonymous. Whereas an efficiency rating measures how well someone performs a task in a given time, Effectiveness Rate simply measures the use of time during the work day.

Effectiveness Rate teaches us that a person cannot be 100% effective all the time, which is at the crux of the problem with “Man Hours.” Let’s go beyond this though and show how this simple concept should be applied in the work place. For example, Direct time is the responsibility of the individual worker to manage, and Indirect time is the responsibility of the manager to manage. Both Direct and Indirect time should be recorded either using computer software (such as a Project Management system) or with a paper time sheet. To make this work, the individual must participate in the estimating process of an assignment. Instead of an estimate being forced on to a worker, as in a micromanagement scenario, the worker is asked to consider the complexity of the assignment and make a personal commitment in terms of the Direct Hours needed to complete the task. As work progresses, the worker posts his/her time to the time sheet/screen and updates the amount of time remaining on a given task, not in terms of “percent complete” but by the number of Direct hours remaining (aka, “Estimate to Do”). This emphasis on estimating and reporting Direct Hours means the individual must supervise him/herself, thereby the manager spends less time supervising the worker. In other words, workers are treated like professionals and are expected to act as such in return.

Because the manager is responsible for managing the work environment, he/she monitors and controls the worker’s indirect time. Again, it should be remembered that a person cannot be 100% effective. If pushed too hard, the worker may start to make mistakes or accidents which would certainly be counterproductive. This is why, for example, Japanese assembly lines will stop periodically to allow workers to back away from their machines and briefly perform some basic exercise before resuming their work, thereby clearing their heads. The exercise is most certainly an Indirect activity that keeps them from their tasks, but it refreshes them and allows them to refocus.

In the average office, each person will have a different Effectiveness Rate which the manager will monitor. Again, there is a big difference between Effectiveness Rate and an Efficiency Rating. To illustrate, a novice worker may have a high Effectiveness Rate, but it may take him/her more time to perform a task than an experienced worker who might have a lower Effectiveness Rate. Here, the manager must consider the skills and proficiencies of the workers when selecting personnel to perform a task. For more information, see my paper on “Creating a Skills Inventory.”

One of the main benefits of Indirect Time, is its use in calculating schedules. For example, if 100 hours have been estimated to perform a given task, under the “Man Hour” approach, the task would be performed in 12.5 business days (assuming an eight hour business day). By studying Effectiveness Rate though, the manager can use it to calculate a more realistic schedule; for example, assuming a worker is 70% effective, this means there are 5.6 Direct Hours in the business day to perform the work, which calculates into 17.8 business days (and substantially different than the “Man Hour” approach). The point is, Effectiveness Rate builds reality into a schedule.

As work progresses on an assignment, the worker reports his/her time which the manager monitors. If the manager observes the worker’s Effectiveness Rate dropping, he will endeavor to determine the reason why and exercise authority to try to raise it (within reason of course) in order to keep the schedule on track. For example, the manager may instruct the worker to minimize personal phone calls and attendance at meetings. By doing so, the manager is controlling the work environment.

To make this all work, the workers need to report their use of time, something that some office workers spurn claiming it is “unprofessional.” Nonsense. Being a professional means you are held accountable for your actions and committed to delivering on your promises. Since professionals such as lawyers, doctors and accountants keep track of their time, why not other workers? If workers truly want to be treated like professionals, with less micromanagement, then they must accurately report their use of time. Bottom-line, this interpretation of the use of time promotes the concept of the “Mini-Project Manager” whereby workers supervise themselves. In other words, the company is managing from the bottom-up as opposed to top-down. If done properly, the manager will find he/she will spend more time managing and less time supervising. The concept of “Man Hours” is simply the antithesis of this approach.

As an aside, this concept can hardly be considered new as it was derived from construction projects in the 1950’s. Do you know what the average Effectiveness Rate of a construction worker is? 25% Call the Ripley people, they don’t even believe it.

Originally Published: October 20, 2009

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  THE GOOD LIFE FOR MILLENNIALS? – Who are the advertisers appealing to?

LAST TIME:  THE NEED FOR EMPATHY  – Does the excessive use of technology affect our compassion for others?

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern); WZIG-FM (104.1) in Palm Harbor,FL; The Glenn Pav Show on WTAN-AM (1340) in Clearwater, FL, Mon-Fri (9-10am); and KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific).  Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management | Tagged: , , , , | 1 Comment »

THE TRUTH ABOUT PROJECT MANAGEMENT PACKAGES

Posted by Tim Bryce on February 17, 2014

BRYCE ON MANAGEMENT

– Do they truly support project management or are they glorified punch clocks?

(Click for AUDIO VERSION)
To use this segment in a Radio broadcast or Podcast, send TIM a request.

I was recently researching project management software for a client. Such software is certainly not new and can be traced back to their origins in the 1960’s with mainframe based packages. Some of the earliest applications of computers in the 1950’s were for such purposes, particularly estimating and scheduling. Nonetheless, I was looking for a PC based package that could also be implemented on smart phones, and geared to reporting an employee’s time. Frankly, I was disappointed with what I found.

I looked at dozens of packages, some free, others for a price; some were PC based, others were “cloud” based, and some were implemented over the Internet. The graphical input was easy on the eyes, but virtually none could implement what I was looking for, regardless of how well they were evaluated by software researchers. Frankly, I think they were looking at the wrong features. Instead of determining their suitability for project management, they only consider the programming, and by doing so, they have missed the boat.

The biggest problem I saw was they all supported the concept of “Man Hours,” which has long been considered a fallacious concept in project management circles. “Man Hours” is nothing more than “Elapsed Time” which doesn’t consider how time is utilized, for example, real work (Direct time) versus interferences (Indirect time). The differences are important. Since Direct time represents worker effort, it should be up to the worker to estimate and control. Indirect time keeps the worker away from his/her assignments and, as such, is up to the manager to control. The analysis of time in this regard is considered an “Availability Rate” matching the Indirect time against the total available time. Office workers typically have a rate of 70% (approximately 5.6 Direct hours in a business day), and construction workers typically have a rate of 20% (approximately two direct hours in a day). By analyzing time this way, more realistic project estimates and schedules can be calculated. As an aside, in no way should Availability Rate be considered a measure of productivity or efficiency; it is nothing more than an analysis of the use of time.

This concept originated from the construction industry back in the 1950’s. As simple and effective as it is, virtually none of the software products I studied took this into consideration, consequently they deal only in “Man Hours” and I suspect their customer’s ability to complete project assignments on time is weak. Further, by not distinguishing the differences between Direct and Indirect, it is likely their customers are micromanaging their workers. In other words, workers are managed top-down, not bottom-up where worker input is used to formulate estimates and schedules.

I also observed some of the packages clung to the concept of “percent complete” for a given task, another fallacious concept. Instead of asking workers the amount of time remaining on a task, they are asked to input the duration of the task thus far. As history shows us, even if a task is 99% complete, the last one percent can seemingly take an eternity. For more information on this, see “Estimate to Do versus Percent Complete.”

Again, all of the project management packages I researched looked slick, but virtually none could solve true project management problems. As such, they were nothing but glorified punch clocks. I find it rather ironic that despite the advances we have made in computing, perhaps the best approach to project management is a paper based solution. I guess I’ll just have to keep looking.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M&JB Investment Company (M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
timbryce.com

Like the article? TELL A FRIEND.

Copyright © 2014 by Tim Bryce. All rights reserved.

NEXT UP:  THE MYTH OF EQUAL PAY – In capitalism, there is no such thing; it’s what the market bears.

LAST TIME:  WHAT’S IN A NAME: TOILETS  – 15 interpretations for the same thing.

Listen to Tim on WJTN-AM (News Talk 1240) “The Town Square” with host John Siggins (Mon, Wed, Fri, 12:30-3:00pm Eastern), KIT-AM 1280 in Yakima, Washington “The Morning News” with hosts Dave Ettl & Lance Tormey (weekdays. 6:00-9:00am Pacific), and KGAB-AM (650) of Cheyenne, Wyoming. Or tune-in to Tim’s channel on YouTube.

Posted in Management, Project Management, Software, Technology | Tagged: , , , , | 4 Comments »

“BRYCE’S LAWS” MINI-POSTERS ON PROJECT MANAGEMENT AND SYSTEMS

Posted by Tim Bryce on October 9, 2012

New “Bryce’s Laws” Mini-Posters for Project Management and Information Systems have been introduced. The popular “Bryce’s Laws” include axioms for a variety of management and technical subjects, not to mention life in general. This particular collection includes ideas pertaining to Project Management (“Manage from the bottom up; not just from the top down; this creates personal commitment and accountability”) and Information Systems (“An information system is a product that can be engineered and manufactured like any other product.”) The Mini-Posters are thought provoking and good conversation starters.

Click on image to download
BRYCE’S LAWS ON
PROJECT MANAGEMENT

Click on image to download.

Click on image to download
BRYCE’S LAWS ON
INFORMATION SYSTEMS

Click on image to download.

ALSO AVAILABLE:

BRYCE’S LAWS ON: LIFE, and MANAGEMENT.

Posters courtesy of M& JB Investment Company, Palm Harbor, Florida.

Posted in Business, Management, Project Management, Systems, Technology | Tagged: , , , , | 1 Comment »

THE VALUE OF THE SYSTEM AUDIT

Posted by Tim Bryce on August 7, 2011

“Systems do not have a ‘life cycle.’ They may go on forever if kept viable with change. The only thing that has a ‘life cycle’ is a project which has a beginning for planning, a middle for execution, and an end for review.”

– Bryce’s Law

“Unless we learn from history, we are doomed to repeat it.” Many I.T. organizations do not grasp the significance of System Audits and, as such, tend to regard such reviews as a waste of precious time and resources. Consequently, systems are installed without any type of follow-up. Because of this, many of the benefits of the system are never realized. For example, clerical savings may have been part of the justification for a new system, but operating management did not reduce or reallocate the staff to realize the benefits. Without a system review, “Parkinson’s Law” may occur where “work expands to fill the time available,” and the system savings are never realized.

As another example, a new management infrastructure, created as a result of organizational changes, may not be effectively utilizing the information provided by the system. They may be unaware of, or lack knowledge about the system. In order for management to have confidence in their systems organization and the systems installed, they should have tangible evidence their significant investments are producing the promised results.

The systems organization can realize many benefits from a System Audit. It is not just a platitudinous statement to say that “we learn from our mistakes”; It is a clear and established fact. A detailed audit provides systems and software personnel with an opportunity to review their estimating and design skills. This knowledge, along with historical data, can be gainfully applied to new systems and projects. As such, estimating guidelines can be updated.

A carefully executed audit can also add to the credibility of the systems organization by showing how well they performed and whether they were accountable for their actions. More importantly, the systems organization may find the new system is simply not functioning in spite of systems maintenance and revisions. In this event, the audit may indicate an entirely new approach should be taken as opposed to continually fighting the problem.

WHEN SHOULD YOU CONDUCT THE SYSTEM AUDIT?

The System Audit should be scheduled for execution after the system has operated for an adequate period of time. Typically, this will be between thirty (30) and ninety (90) days after implementation. In some instances, it may be necessary to conduct more than one audit, depending on the timing of implementation and execution of the various sub-systems within the system. For example, users may want a detailed accounting of project costs immediately after startup. The actual system evaluation can follow thereafter.

HOW SHOULD YOU PERFORM THE SYSTEM AUDIT?

Ideally, the audit should not be performed by the same individual(s) who developed the system. A neutral third party should be involved who can audit the system and project objectively.

The steps required to execute the System Audit are similar to:

* “Current Systems Analysis” – the intent of this activity is to study the existing system, sample work, and evaluate strengths and weaknesses. This same type of work is performed in the System Audit. Here, the Systems Analyst uses the systems documentation to walk through the system.

* “Prepare System Evaluation” – the intent of this activity is to estimate and schedule the remaining work effort, and perform a Cost/Benefit Analysis. During the System Audit, the Project Manager examines actual time reported, costs incurred and delivery dates. A final Cost/Benefit Analysis is calculated based on actual data (not estimated).

AUDIT CONSIDERATIONS

During the System Audit the Systems Analyst may identify errors, omissions and severe weaknesses in the new system. In this event, the analyst may initiate a Work Request to document a modification/improvement. This will then go through the normal process of evaluation and priority calculation.

A Project Management (PM) system can assemble all pertinent project data for analysis. This data can also be exported to other financial packages and spreadsheets for further analysis as required.

CONCLUSION

There are those who see System Audits as a waste of time and would rather scramble off to other assignments. As for me, I have always found the System Audit as an invaluable opportunity to fine tune the skills of the development staff and improve the standards and techniques used throughout the methodology. For example, after one System Audit we found it necessary to upgrade our programming standards to better promote consistency. We also found it necessary to obtain a prototyping tool to expedite the development of screens. This materially impacted subsequent projects which benefited from the System Audit.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Like the article? TELL A FRIEND.

Tune into Tim’s THE BRYCE IS RIGHT! podcast Mondays-Fridays, 7:30am (Eastern).

Copyright © 2011 by Tim Bryce. All rights reserved.

Posted in Project Management, Systems | Tagged: , , , , , | Leave a Comment »

ESTIMATING – GETTING IT RIGHT

Posted by Tim Bryce on July 17, 2011

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I’ve long given up looking for panaceas. Actually, I have always regarded estimating as a relatively simple task and have taken my queue from the construction industry who has had to frequently produce reliable estimates over the years. As such, there are basically three variables involved:

* Methodology – defines the stages of work by which projects are completed, from beginning to end. Some portions of the project will be executed serially, others in parallel, either way, each stage should define precisely what work has to be accomplished to the types of components involved. Typically, components are identified, designed, tested, and installed in moderation which is commonly referred to as “stepwise refinement” (going from the general to the specific) as prescribed by the methodology.

* The components involved – in the construction field, it is the wood, stone, glass, nails, rivets, steel beams, etc. to be used to construct a building. In the I.T. field it is the data elements, records, files, input, outputs, programs, business processes, etc. The methodology dictates the sequence by which the components are implemented. A component assembled at the wrong time and place will likely prove disastrous, which is why the methodology is so important. To make this work, it is necessary to produce a rough design of the object in question. For construction, it would mean a complete rough design of a building, aka, “artist rendering.” In I.T., it would mean a complete rough design of a system or program. Only after the rough design has been completed can a listing of the components be identified.

Another consideration is the state of the components, how many are new versus how many can be reused from other projects. To illustrate, if there are already preexisting nuts and bolts to satisfy the product, they certainly can be reused; if not, new nuts and bolts have to be designed. Within a systems development project, if a data element such as “Customer Number” has already been invented and implemented, there is no point in introducing a redundant component; developers should simply reuse the existing data element. Such reusability of components not only expedites development time, but promotes integration of different products.

“Bill of Material Processors” (BOMP) are commonly used to keep track of components, be it in the construction field or I.T.

* The skill of the people charged with executing the project. A novice worker will obviously take longer to perform a given task than an experienced expert. This is also why it is preferable to have the people charged with the work participate in the estimating process as it becomes a reflection of their commitment. In a situation where project personnel are unknown, the Project Manager can still render an estimate based on “averages” defining the amount of time necessary to build a component for a given task. As projects are executed, the actual time expended to complete a component for a specific task should be captured so such averages can be refined based on historical data.

This approach to estimating is universally applicable to any product development based project. It is based on the recognition that most estimating errors are errors of omission, not commission. It is the forgotten or overlooked components that lead to most estimating errors. Again, this is why the rough design is so vital as it will overcome the problem of omissions. As in any construction project, a rough architectural design is required to effectively estimate the project to build it. The same is true in I.T. projects where the objective is to build a new system. To do so, a complete rough design of the system must first be prepared to effectively estimate the remainder of the project.

This approach also distinguishes the use of time as either “direct” or “indirect.” Whereas direct time represents whole work, indirect time represents interferences detracting from project execution. Estimates should be expressed in direct time, not indirect time, as we want to know the amount of pure effort needed to complete a component and task. This approach to time also implies estimating and scheduling are separate activities. Whereas, direct time is used to express estimates, indirect time is used to calculate schedules. For example, if an estimate for a project task is ten direct hours, and a worker is only able to spend four direct hours of work each day (with another four indirect hours spent elsewhere during the day), the task should be completed in 2.5 working days. Separating time into “direct” and “indirect” greatly improves precision in both estimates and schedules.

Here is a typical scenario for estimating a product related project, be it construction, I.T., manufacturing related, or whatever:

1. Specify and analyze requirements.

2. Prepare a rough design of a product to satisfy the requirements.

3. Prepare an itemized listing of components to be used in the product, aka, “Bill of Materials,” identifying which are new and which can be reused.

4. Based on the materials, define the remaining stages of work to develop the product (the methodology).

5. Estimate the amount of time necessary to complete the various stages. If project personnel are known, have them participate in the estimating process.

6. After the estimate has been defined, calculate the project schedule based on the methodology and use of time (direct vs. indirect).

7. Review with the client for approval.

This approach is certainly not new and has been used for many years in a variety of industries. Ultimately it represents a complete mental execution of the project in order to determine costs. This is essentially no different than what a professional golfer does before swinging his club on a drive; he visualizes everything from how he is to swing the club, the follow through, to where he wants the ball to land, and the ensuing strokes necessary to complete the hole. Preparing a rough design is no different. It is thinking the project through to completion by considering all of the components needed to satisfy the product. Will it be perfect? No, but it will be more accurate than making wild guesses based on some wild pseudo-scientific calculation. The only drawback to it though is it requires some hard work in upfront planning and design; it is certainly not a panacea, but then again, there never has been any magic in estimating that I know of.

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Like the article? TELL A FRIEND.

Tune into Tim’s THE BRYCE IS RIGHT! podcast Mondays-Fridays, 7:30am (Eastern).

Copyright © 2011 by Tim Bryce. All rights reserved.

Posted in Project Management | Tagged: , , , , , | Leave a Comment »

MANAGING FROM THE BOTTOM-UP

Posted by Tim Bryce on September 22, 2010

“If we lived in a perfect world, there would not be a need for managers.”
– Bryce’s Law

When the American colonies were forming a government in the 18th century, there was a fleeting notion that George Washington should become King with absolute power. Instead, our founding fathers opted for a democratic society where officials were elected by the people. The intent was to give the individual citizen a means to participate in the running of the government. This was a wise decision and has served America well for over 225 years. By being included in the process, people align their loyalties to the government and country, and are quick to come to its defense in times of national emergency. Involving the individual is a simple gesture that has had long range positive effects on our country.

It is an interesting dichotomy that whereas our country involves the individual, most of our other institutions do not. I have been fortunate to have traveled the world and have seen many different types of companies, from large to small, and in just about every field of endeavor imaginable. Most are run top-down with a benevolent (or maybe not so benevolent) dictator at the helm. Assignments, estimates and schedules are pushed down the corporate chain with little regard for the individual employee.

Over the years there has been a lot of discussion about Theories X, Y, and Z in management; whereas “X” is autocratic, “Y” is more of a “carrot and stick” mentality and “Z” promotes individual participation. Remarkably, despite the many years of promoting the rights of the worker, today we primarily live in a Theory X world. Employees are told what to do and when to do it, without any interest in their input. Today, this is commonly referred to as “micromanagement.” Under this approach, although the work will eventually get done, there is no loyalty to the company by the employee, mistakes are made and quality suffers, and productivity declines since there is no personal sense of urgency by the employee. In other words, the company works, but not like a well-oiled machine.

More recently, I have noticed this same phenomenon occurring in non-profit volunteer organizations, such as homeowner associations, clubs, school organizations, sports associations, even church groups. The people that run these groups may have the best intentions, but rarely do they know how to actually manage. Sadly, some people get involved with such organizations to satisfy a petty power trip they are on. Consequently, they have little regard for organization and adherence to policies and rules. Instead, they try to micromanage everything. People, particularly volunteers, have a natural aversion to micromanagement and quickly lose interest in their work.

Let us always remember that the word “management” begins with “man” for a purpose: it refers to how we interact with people and, as such, it is not a clerical or administrative function, but, rather, a people function; how to work with the human being, a very challenging task considering you are dealing with human beings who can be emotional, irrational, and just plain “thick.” There is a countless number of books on the subject of “management” alone. But for our purposes, perhaps the best way to think of “management” is simply “getting people to do what you want, when you want it, and how you want it.” If we lived in a perfect world, there would not be a need for managers; people would know what to do, and projects would be executed on time and within cost. However, as we all know, we live in an imperfect world. People do make mistakes and problems arise, hence, the need for “managers”, people charged with assigning and directing the work of others. Managers are in the business of solving problems; people problems!

Some of the most productive organizations are those where management succeeded in getting the individual workers involved with the running of the company. Sure, management is still in control, but they have stimulated employee interests by encouraging their participation and feedback. Management still has some top-down responsibilities, including:

1. Delegate – prioritize and assign tasks to qualified employees.

2. Control work environment – minimize staff interferences and provide a suitable workplace to operate with the proper tools to perform the work.

3. Review progress – study employee reports and take corrective action where necessary.

Individual employees have bottom-up responsibilities to management:

1. Participate in the planning process – review work specifications and give feedback; estimate amount of time to perform an assignment, assist in the calculation of work schedules with management.

2. Perform work within time and costs constraints.

3. Report activities to management – including the use of time, interferences, and possible delays.

In this bottom-up approach, employees are treated as professionals and are expected to act as such in return. This results in far less supervision as found in micromanagement. Employees are delegated responsibility, supervise their own activities, and report to management on progress. This approach will work in any business, be it a corporation or non-profit volunteer organization. There is only one catch to this approach: some people resist assuming responsibility for their actions and prefer to have someone else tell them what to do; thereby when something goes awry, they can blame the other person for the snafu. This type of person is more suited for a dictator type of organization where they can continue to grouse about management, yet do nothing to help correct the problem. Aside from this, the benefits of the bottom-up approach far outweigh the negatives. It is simple and it works.

“Surround yourself with the best people you can find, delegate authority, and don’t interfere.”
– Ronald Reagan (1986)

Keep the Faith!

Note: All trademarks both marked and unmarked belong to their respective companies.

Tim Bryce is a writer and the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at timb001@phmainstreet.com

For Tim’s columns, see:
http://www.phmainstreet.com/timbryce.htm

Like the article? TELL A FRIEND.

Tune into Tim’s THE BRYCE IS RIGHT! podcast Mondays-Fridays, 11:30am (Eastern).

Copyright © 2010 by Tim Bryce. All rights reserved.

Posted in Management, Project Management | Tagged: , , , , , | Leave a Comment »