|
|
|
Published: November 26, 2005
Print
Email
The project process begins with the definition of purposes, objectives, and strategies and concludes with a postproject review.
Define the Purposes, Objectives, and Strategies Every project begins with a clear delineation of its purposes, objectives, and strategies. I refer to these three as the up-front work that is seldom performed with sufficient diligence. Even a research project, in which there are often many unknowns, requires a description of its purposes, objectives, and strategies, although every "i" may not be dotted and every "t" may not be crossed. Since research resources are generally discretionary it becomes doubly important to allocate those resources toward some objective, preferably an objective that has a high priority for the organizational unit.
Keep in mind that projects are made up of teams. How you proceed with a project depends on how and to what extent you frame the project. Framing is a process by which we define the ends to be achieved, the means to achieve those ends, and the decisions to be made in the process. Framing is accomplished by beginning with fuzzy facts that are uncertain and making some sense of them. So how we frame the proposition, question, or problem makes a considerable difference. President John F. Kennedy did not describe the objective as putting a man on the moon but putting a man on the moon and returning him safely by the end of the decade. Note that this vision includes putting a man on the moon and returning him safely within a specific period of time. This vision of the effort is significantly different than if he had simply said put a man on the moon.
Projects such as bringing a new widget to market, restructuring the organization, providing new manufacturing facilities, changing the organization's logo, providing new financial instruments, developing wetlands, making government entities more productive, or introducing new programs to an academic institution need a well-defined statement of purpose. Most managers feel that their projects are fully defined, but then why do so many fail to meet expectations? In the interest of saving time, managers often fail to ask some simple questions, such as:
- What are the benefits if the project is successfully completed?
- Why are we investing resources in this project?
- What are the implications if the project does not proceed?
- Does the project fulfill the organization's vision?
- Does the project move the organization closer to what it wants to be?
Describing the project objectives brings us to the nitty-gritty of what we hope to accomplish. Objectives are reached through developing goals that must be reached if the objective is to be met. Every project of any significance requires a clear delineation of those goals; call them subobjectives, if you wish, but they must be defined. Too often the objectives are not fully defined, and thus begins the journey down the trail of limited resources, scope changes, and beginning of the blame game.
As an example, a project objective might be "build a house of a certain size in a specific geographic area at a particular cost." But what other factors would you need to communicate to the project manager? There are many different styles to choose from; the exterior could include many different finishes; the rooms could be large or small; the driveway might be circular or straight; and so on through many other potential choices. If you don't define those elements, the finished product will not meet your expectations. Too many projects begin with we need to do this without a full understanding of just what this includes.
Every project also requires a strategy for accomplishing its goals and objective. Obviously it should meet the strategic direction of the organization, but I'm referring to the strategy that will guide the project. Strategy answers the question of how: How are you going to go about meeting those objectives? What's the plan?
Agree on Preliminary Assumptions Too often little thought is given to developing preliminary assumptions. How clearly those assumptions are delineated will determine the number of times the panic button will be pushed. You need to document the known and unknown, the controllable and uncontrollable, and the predictable and unpredictable. The unknown, the unpredictable, and the uncontrollable must be rationalized now; it is very easy to disregard these three "UNs" until later stages of the project. The time to begin working on them is now.
Laissez-faire project management doesn't work. You can't make up the game as you go along. People need a modus operandi, especially if a large number of players are involved. The best results are achieved when everyone plays from the same sheet of music. Keep in mind that as new information becomes available changes in direction may be required. The project team must be able to accept these changes.
Conduct the Required Study Most projects require some research or study that adds new information. If no new information is required, you might question the necessity of pursuing the project: just more of the same may not provide any competitive advantage. There are competitors who will challenge the best and the brightest. Those challenges require a response. The question usually revolves around how much research or study is necessary. Too little information may not provide an acceptable approach and too much information can be costly and time consuming without providing any appreciable benefit.
Reexamine Preliminary Assumptions As the project progresses, take the time to reevaluate those preliminary assumptions. You need the full team to do a proper evaluation since you will probably not be current on the requirements of each discipline that's involved. Unfortunately and too often, any information that somehow contradicts the basic assumptions will be greeted with much skepticism. Plans were based on those preliminary assumptions but plans are not cast in bronze; they're a guide to achieve a result and should be modified when necessary.
Identify Alternative Solutions Taking time to evaluate alternative solutions can pay big dividends, but deciding how many to consider is a judgment call. It takes more time to evaluate alternative solutions, but the process provides a high degree of confidence. It's easy to apply a quick fix without any consideration of the system or future needs. You need to keep in mind that there is seldom a perfect solution; there is only the most appropriate one from a group of possible solutions that can be implemented through the available resources and infrastructure. Identifying alternatives also involves estimating the results from each solution. While financial results are the easiest to measure, they may not always lead to the right choice. Those nonquantifiable issues of each alternative require consideration. That calls for judgment.
Select the Solution There is no prescriptive method for selecting the appropriate solution. Some simple questions can be asked:
- Is the solution realizable within the organization's financial and structural limitations?
- Does the solution meet all of the project requirements?
- Does the solution provide for use in pursuing future opportunities?
- Does the solution leverage the current bank of the organization's proprietary knowledge?
- Is the required level of expertise available within or outside the organization?
- Is there a project manager available with the required credentials, experience, and track record?
These are basic questions and need to be expanded based on the project's scope and importance to the organization.
Define Resources, Cost, and Timeline Projects succeed or fail depending on the available resources, the accuracy of cost projections, and a realizable timeline. As a rule we don't do a very good job of defining project resources; too little emphasis is placed on track record and too much on academic credentials. I suggest that educational background be given secondary consideration for any person who has been out of school for more than five years. There must be a balance, and the track record should take precedence.
Estimating project cost creates difficulties for most people. Yet the costs determine the viability of the project. It's very difficult for a manager to identify all costs without the help of the group. But group members are often reluctant to commit to some fixed number of hours because they'll be expected to meet their commitment. Organizations differ on how cost projections are made. Generally for major projects, the project manager will develop those costs with considerable assistance from the accounting department or the subunit's assigned controller.
After the timeline is presented to upper-level management, the response may be: that's not good enough; we need the project completed within the next twelve months. A give-and-take discussion follows: it can't be done, why not, what do you need to meet the twelve-month schedule, and so on. Eventually, an agreement is reached but in too many cases the timeline is unrealistic. This is why we never have enough time to do it the right way but plenty of time to do it over. Timelines must be realistic and can usually be met by modestly limiting the initial scope of the project without seriously limiting the expectations.
Work Breakdown Structure Technology-oriented departments are familiar with work breakdown structure but administrative and distribution functions seldom use it. Very simply, work breakdown structure divides the project work into many tasks. This provides a way for understanding the pieces and also understanding how those pieces must come together and at what time. The work breakdown structure also puts the tasks in some order for completion and develops priorities. There is a tendency to focus early attention on what's known rather than on resolving the unknown issues.
Estimate Cost/Benefit While project cost is important, estimating the cost/benefit of the solution is of equal if not greater importance. The benefits to be derived from the investment of resources determine whether the project will gain approval. Organizations generally use some form of cost/benefit analysis for approving projects: payback period, net present value (NPV), return on investment (ROI), and modified forms of each of these. They are tailor-made to the organization and also include some minimum hurdle rate for approval. For projects that have no direct financial benefit, some sort of cost/benefit analysis must still be developed.
Consider this example: the human resource department suggests introducing a new performance appraisal system. The costs can be developed without any difficulty, but the benefits are difficult to measure if required to meet some financial hurdle rate. Those costs basically include the time required to accomplish the appraisal process, and since new appraisals usually become more complex and are done more often, they require more time, which can add considerable cost.
Evaluate the Risk Every project requires an evaluation of the risk involved. Success is not guaranteed regardless of the effort put forth in diligently developing the background information. There is a difference between managing the uncertainties and evaluating risks. Uncertainties include that complete list of unknown and unpredictable issues. Resolution of the unknowns can be accommodated, but the unpredictable elements need to be addressed throughout the whole project. The level of these uncertainties determines the risks that must be evaluated in relation to the organization's ability to accept the risk.
Prepare an Implementation Program Implementation plans must meet the needs of the project. Some may be very simple and others complex, but all must be straightforward and direct. They may be extensive in detail, but the detail should follow to a logical conclusion without any gaps. The what, the when, the where, the how, and by whom must be answered.
Managing the Project Processes Once the project has been approved and work begun, there are activities that need to be reevaluated frequently throughout the life of the project. All the data accumulated during the project approval stage needs to be under constant evaluation. New competitors may have entered the field; new technologies may have surfaced; new markets may have become apparent; new government regulations may have been imposed; budgets may have been reduced; and the organization's direction may have also changed.
Continue Evaluating Priorities Priorities will change during a project because what may have been considered as a known becomes an unknown. New information was uncovered that needs to be addressed. Certain tasks were initially defined, and in the process of completing those tasks the original assumptions were invalidated. You need to go back to the drawing board, so to speak, to find a new solution if the project is to meet its time schedule. Also events and tasks that are listed as predictable often prove to be unpredictable and troublesome because other expected results were not achieved.
Control Scope Creep Scope creep involves adding features to a project after it has been approved; it is one of the major issues that prevent organizations from completing projects within specification, on time, and at estimated cost. At the very least scope creep increases cost, often requires time-consuming rework, deprives other value-adding projects of resources, delays the launch of the project's output, and can cause a loss of major business opportunities. But scope creep will always be with you and you need to find ways of controlling it. The amount of scope creep depends on the rigor that was applied during the stages prior to management approval. Well-conceived projects should not require any major changes in scope, but you need to recognize that perfection is not attainable, so there will inevitably be some changes that will have to be implemented.
Control the Documentation Not very many people care to update the project's documentation. Let's face it, it's a boring job, it doesn't require any creativity or innovation or personal initiative, and yet it plays a major role in determining future actions. The past history is important both from the managing and operational perspective. Documentation covers all functions and disciplines. There is no excuse for sloppy documentation. Just think back over your years as a professional and calculate the lost hours because prior work wasn't properly documented. Proper documentation involves keeping a running history of the project and documenting events, changes in direction and scope, and modifying plans as required.
Project Reviews Project reviews are not a matter of choice, especially when the project involves several disciplines and departments. Regardless of their high levels of competence and dedication, people must be brought together in some type of forum to review the project status. Those pieces of the puzzle must fit into the right places. There may be misunderstandings of the requirements that need to be clarified. There may be conflicts in design parameters. New information may have been uncovered that requires changes. Unless these problems are corrected in a timely manner, much of the work effort can become useless.
The greatest pitfall of all project reviews is a lack of candor about the real situation. Those formal presentations often fail to tell the complete story. We are all aware of projects that are on schedule for a year or more and in the last week require additional months to complete. Every review must focus attention on the knockouts, which are those items that if not resolved in a timely manner will in essence scuttle the project. They must be identified and resources provided to resolve them. Wishful thinking will not provide the answers.
The project manager takes total responsibility for the project and needs firsthand information about the status. Depending solely on project reviews really doesn't work. Making decisions solely from those written reports and checking the latest project management computer program isn't enough. Project managers need to get into the act without micromanaging. There's only one way to determine the status of a project: do your own investigation. That doesn't imply that you don't trust your people, it means you want to know what's going on.
Whom you appoint as a project manager does make a difference. The project manager should have some understanding of the disciplines involved in the project; not necessary at the expert level, but some understanding. At a project management conference I met with a group of software developers for a general discussion of project management issues. The session quickly deteriorated into a criticism of their project managers. This was the first time I had heard such vociferous criticism of project managers. After much discussion of the issues I focused attention on the background of the project managers. All but one was a recent MBA graduate without any understanding of software development, which is not a very good set of credentials for a software project manager. It's important that project managers understand what they're managing.
Develop a Project Control System How much project control do you need? Just enough; not too much, not too little. Forget about the war room approach with all the graphs and data. Much of the reporting is irrelevant. A project is made up of a series of tasks derived from the work breakdown structure that are assigned to a specific individual or group. Each of these tasks has a specific requirement, a completion date, and a cost. So there are basically three factors to track. The status of each task against its goal is a judgment call; you're not counting widgets coming off the production line. You're looking at the results of the thinking that has taken place in order to resolve some specific issue that can't be quantified by some algorithm. The cost data is quantifiable and useful if presented in a timely manner and includes all associated costs. The schedule is quantifiable; you either have or have not met the expectations as originally defined for some point in time. There are no "almost yes" answers, only "yes" or "no." A "no" answer requires a statement of the problem and a means for resolving it.
There are many project management software programs available for project control. The challenge lies in determining which one fits your requirements. My comments are not made to set you against computerized project planning and monitoring, but to help you avoid the necessity of dedicating a full-time person to manage the program and develop data that provides little if any benefit. So while the choice of program is important, it is only a means to some end; it is not an end in itself. It's a tool to help manage projects more effectively.
Some project management programs are merely scheduling programs. Others go into extensive detail, providing tools for team selection, tracking start and finish dates of each task, hours required from each individual, automatically updating the complete program in the event of some missed target date, identifying direct and overhead costs, requesting information based on prior considerations, and an array of issues that may or may not be necessary for your particular group. The question always remains: What information do you and your project managers need to manage your projects? There is no one program that fits all situations and data should only be generated if the data adds value in some way.
Postproject Review The value of a postproject review, or postmortem as some choose to call it, cannot be overemphasized. It provides an opportunity to assess the overall quality of the project effort. But the review is only valuable if issues, those having either a positive or negative impact, are brought to the surface and discussed openly. Positive performance issues may be subsequently designated as best practices. Dealing with the negative aspects of the project presents greater difficulty. The discussion cannot deal with personnel issues; that discussion if necessary should be done in private. The group should be asking two simple questions: What did we do well? What did we do not so well?
Questions may relate to the clarity of the project statement, the description of the goals and objectives, the planning process, the work break-down structure, the use of resources, the communication system, the information system, the original schedule and cost estimate, the changes in scope, the project management system, timely decision making, and any related issues. This exercise is not done to post a grade but to learn from the experience and in the future take advantage of the positive practices and try and eliminate the negative practices.
Discuss this article in the Forum!
« Back
|
|
|
|
|
 Home |
|
|
|
| Exclusive Content & Services |
|
|
|
|
|
