Project Decisions
Project Decisions
By Dave Nielsen
During the life of any project, many decisions must be made. The number and importance of these decisions will depend on the size and complexity of the project, but it is safe to say that any project will have some decisions and managing these is a critical part of the project manager’s job. How you manage these decisions will depend on several factors: whether the decision is yours, whether it is a gating decision, or whether the decision would change the scope, schedule, or budget of the project.
Let’s take a look at the higher profile decisions first. Perhaps the most prominent of decisions you are responsible for is the gating decision. This decision determines the fitness of your project to proceed to the next project phase and in the case of the decision to proceed from the planning to implementation phase; it can have a lot of money riding on it. Your job is not to make the decision, although you will be in a position to influence it.
Your job is to identify the right set of criteria your project must meet in order to proceed to the next phase. The criteria your project must meet will depend on the phase just completed but can generally be divided into work completed in the last phase, and resources and plans necessary to begin the next. That the work of the previous phase is complete is verified by the presence and completeness of its deliverables. The deliverables you choose as your criteria should be those that are visible to the decision makers. For a gate decision to proceed from the planning phase to the build phase, your deliverables will be project plans, scope statements, Statements of Work, requirements documents, signed vendor contracts and the like. For a gate moving the project from the build phase to the closeout phase, these deliverables will change to the objects, applications, and systems that support the business case for the project. This article is not intended to educate the reader on gate review meetings. For more information on that topic you might want to read Successful Gate Meetings elsewhere on the three o website.
Once you have identified the criteria necessary for the decision, identify the decision makers. If you’re lucky enough to have a Steering Committee providing oversight on the project, you need look no further. Failing that, your project sponsor should be able to help the decision makers. Give these folks lots of advance notice of your meeting and prepare your gating criteria in a format that they will be easily digestible. Don’t forget these people won’t be prepared to focus on the minutiae of your work.
Your objective for the gate meeting is to achieve a “go, no/go” decision on whether to proceed to the next phase. Don’t get hung up on the Boolean nature of the decision though. It’s perfectly acceptable to make a “go” decision contingent on some overlooked or incomplete deliverable being available in the next phase, when it is needed. The first slide in your presentation should speak to this decision. You may or may not find it necessary to define the process for making the decision. Keep in mind that the people in the room will probably be senior; be careful not to draw unwanted attention to differences in their seniority.
Keep your gate review brief and to the point. Contentious issues should already be addressed before you reach your gate meeting. In cases where you know, or suspect, you may have issues, you may want to hold a pre-gate meeting with your team and non-decision making stakeholders to flush these issues out so they can be addressed prior to your gate meeting. You should also be prepared to answer any questions your decision makers are likely to have about the deliverables or resources you are discussing. For example, why does your project need 10 programmers (or plumbers) when Jane’s only required 8? You may want to have an SME accompany you to the gate review to answer technical questions beyond your ability to answer. An inability to answer a technical question shouldn’t prevent a gate decision; this is where the contingent or conditional go comes into play. A deliverable not quite completed to a decision makers satisfaction, or a question unanswered can be addressed by an action on your part that will complete the deliverable or answer the question. You will need to record these items in an action register for the meeting and report back to the decision makers when the items have been closed.
Another important piece of information necessary for the decision, which I haven’t addressed, is the business case. The project is being undertaken to produce a positive result for the organization undertaking it. This result will be spelled out in the business case as increased revenue, increased profit, reduced expenses, correction of an operational problem, upgrade of a system to meet new technical or legislative demands, or an intangible benefit. The meeting should verify that the benefits are still as described in the business case and that the cost is still in line with that predicted in the business case. The business case should be updated to reflect the most recent forecasts. If the project does not have a business case, cover these benefits and costs from another source such as the project charter.
Changes to the scope, schedule, or budget of the project are another key decision area. These decisions should be governed by your project change management process. The process should define who the decision makes are, how information necessary for making the decision is to be gathered, how that information is to be tracked, and who is responsible for each step in the process. Doing all this should ensure that your project gets the benefit of good decision making. What it won’t do is guarantee that decisions are made on time, and without that element, your quality decision may be rendered worthless.
Each decision will have a timeline unique to it. The timeline may be explicitly stated in the requested change. For example, a request to change a product consumed by the project in favour of another which happens to be on sale should have the sale date in the request so everyone knows the deadline for rendering the decision. Other timelines will be less clearly defined. They may be implicit in the request such as a request to change the functionality or a software feature. That decision should be rendered before the application is built. It is your job to analyze the request and determine the deadline for the decision. If this analysis requires more technical knowledge than you possess, you must get the information from an SME who is able to determine the timeline.
Knowing the “best before date” of the change request is all that is required if you are the decision maker. Where a change control board is required to make that decision, adhering to the timeline may be a little more difficult. Your CCB should meet regularly and your first step should be to fit the decision on your requested change into one of these meetings. Choose the soonest available date where decisions are needed quickly. If the next available date would be too late for your decision, try arranging a special meeting which will meet your deadline. You will need to explain the urgency of the decision in order to attract the members of the CCB to the special meeting. If you find that impossible to do, go to your sponsor and ask for a decision. In the worst case scenario, where you find it impossible to get a decision from your CCB or your project sponsor, take the bull by the horns and make the decision yourself. This may sound risky but as long as you’ve availed yourself of all the information necessary to make a sound decision, and consulted all the right SMEs, you’ll probably find your initiative will be rewarded. In the worst case, you’ll find out you are on the wrong project.
Many project decisions, at least on software projects, are those rendered by a group of SMEs who are responsible for reviewing the plans, documents, and designs of the project, and providing feedback. The document or design is approved once the feedback has been reached. Decisions here are often delayed because these people are very busy, or don’t understand the urgency of meeting a deadline. Your job is to ensure that the value these people provide to the quality of the document or design they are responsible for reviewing is obtained while still meeting project timelines. Be clear with your deadlines. Don’t send the document out for review without providing the deadline and the reason for the deadline, and then hold the reviewers accountable for meeting that deadline, in the same way you would hold them accountable for meeting any other project deadline. Ensuring your reviewers understand the reason for the timeline should ensure there response. In case their response is not received on time, you have a decision to make: go ahead and approve the document for use without the feedback, or delay the project until you get the feedback. Make sure you render your decision on time.
Replacing individual review and feedback sessions with a group “walk-through” is an alternative that has 2 benefits: it adds the value of the group to the process, it can usually be completed in an hour or less, and you control the timing. Walkthroughs are an excellent tool for validating code but can also be used for the review of any project document by a group of SMEs.
Every decision made on your project comes with a “best before date”. Some “best before dates” are explicit and easily identifiable, others are implicit and require some sleuthing to determine. Your job is to identify the date, identify the decision makers, and then get the necessary information in their hands so they can meet the date. Keeping your eye on these keys to decision making will help your project deliver on time.
Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt©. Dave was also the key architect responsible for the creation of the product. AceIt© has prepared Project Managers from around the world to pass their PMP® exams. You can find endorsements from some of his customers on three O’s web site (http://www.threeo.ca/).
