Cornell Project Management Methodology
CPMM Frequently Asked Questions:
Project Initiation FAQs
Project Planning (High Level) FAQs
Project Planning (Detail Level) FAQs
Project Execution and Control FAQs
Project Closeout FAQsHow am I supposed to make others understand the importance of the Project Charter?
It is your responsibility to provide information that is sufficient to enable the Organization's executive management to understand the value of your project in the written Charter. Show the benefits. Identify the targeted Customers. Explain the significance of the product. Illustrate the value at the level necessary to promote a clear understanding. Use the Charter to educate the executive management of the merits of your idea.Why should we expend the time and effort to create a charter when we could just start doing the work?
If everyone followed this philosophy, the organization would be pulling itself in so many directions that perhaps nothing of value would ever get done. Managers and executives need to manage the work of the organization to ensure its alignment with its mission. Charters provide executive management with the information they need to manage the organization's resources.
What if no one will agree to be the Project Sponsor?
Although no one may have assumed the official role of Project Sponsor, someone secured the funding for this project, and someone appointed you to manage it. Talk to that person, explain the role of the Project Sponsor, and notify him/her that you will consider him/her your Project Sponsor unless someone else is identified to fill that position.What happens later on if my time/money estimates are off by 50 to 100 percent?
Accurate estimating takes a lot of effort, knowledge, available historical data, and a bit of luck. Chances are, your estimates are going to be off; the only questions are, by how much, and what will you do about it.
Your lack of accuracy could be due to one or both of the following: (1) you did a lousy job estimating (usually due to lack of historical comparative data) and/or (2) things changed. In the first case, take responsibility for your mistake, use it as a "learning opportunity," and make sure everyone realizes what you are doing. In the second case, make sure everyone's aware of the changes as soon as they occur, and use the change control umbrella to cover you. Remember – management hates "surprises." It is better (for your career, at least!) to be off by a lot if everyone knows about it well ahead, than to be off by a little – and have it be a total surprise to the decision-makers.
In both cases, it behooves you to document your estimating process and assumptions, and reforecast on a regular basis. If an underestimate becomes apparent, identify root causes, define corrective actions and alternatives, and work back with the Project Sponsor to head off any significant degradation of Project Schedule.
Project Planning (Detail Level)
How do I justify the detail planning time to the Project Sponsor or Customer who just wants it done?
It's called "Customer education." Encourage your Project Sponsor and your key Customers to read (or at least peruse) the CPMM (Cornell Project Management Methodology) Guidebook. Explain to them the benefit they will derive from proper planning. Illustrate your arguments by pointing to other projects (hopefully, disastrous) and explaining why they failed (hopefully, due to lack of planning). Seek persuasive allies among their colleagues. And finally, use it as a continuous improvement opportunity: explain what has to be accomplished, and ask for a creative way of getting the same result using some other means. Who knows, they may actually come up with a process improvement that you can use as a best practice later on.What can you do if the Performing Organization doesn't recognize the importance of project management or feels that they can do it better?
This is a kind of variation on the theme of the previous question. You can either try to persuade the folks that it's the right thing to do, or lead by example and just do it the right way. It is unlikely that everyone doesn't understand project management; seek out people with similar ideas, and have them bolster your arguments. Seek assistance from such places in your organization that support Project Management (i.e. CIT Project Management Consulting Practice) with justifications and examples of successful projects done right.Is the Project Manager expected to perform all of the tasks required of the role? Can some tasks be delegated in whole or in part?
Great question! Management means "getting work done through others." Delegation is one of its principal tenets. Depending on the size of the project, the Project Manager may be physically unable to perform some of the duties outlined in this book. For example, take new team member orientation. Ideally, the Project Manager would spend a chunk of time with every team member, inculcating proper disciplines and techniques. However, what if the Project Team comprises hundreds of members? Project Team Leaders must be identified to take on those responsibilities. But remember, it is still the Project Manager's responsibility to verify that delegated tasks are being executed correctly.
The most succinct way to answer this question is this: the Project Manager must do whatever it takes to have every task done right, on time, and within budget. Whether you accomplish this by sitting on the beach and firing off occasional e-mails (improbable), or by spending all your waking moments in the office (undesirable), you are still doing a fine job.What do you do if the Project Sponsor doesn't fulfill his/ her role to the level of satisfaction expected by the Project Manager?
The first thing to remember is it doesn't pay to fight your Project Sponsor. The Project Sponsor is your principal ally and benefactor. Reason, persuasion and education are the way to go.
First, make sure your Project Sponsor knows that you are both trying to accomplish the same goal: to solve a business issue with the product of the project. Second, make sure the Project Sponsor understands – and agrees with – the approach the project is taking. Finally, once you have established commonality of interests, you can gently educate your Project Sponsor on the responsibilities of the position, and if his understanding differs, try to come to terms to which you both agree. Always approach from the benefit standpoint, explaining how a particular action on his /her part will benefit the project – and eventually the Project Sponsor.
How can a Project Manager manage the Project Schedule if team members don't accurately report when they are behind?
The key to accurate forecasting and precise reporting is the "Current Forecast (Estimate to Complete)" column on the Status Report. The team members don't have to report that they are behind; you (and most likely, your team leaders) need to make sure that they come up with an accurate estimate to complete, and the math will tell you the rest. How do you know if their estimate is accurate? Unless you (or your team leader) are involved in the details of the task, and understand the technology used to perform it, you won't – the first time.
By next time, you will know the team member's bias – unbridled optimism (forecasting too little), gloomy pessimism (forecasting way too much) or random don't-have-a-clue (forecasting erratically), so you can "guide" them to a better estimate and then hold them accountable for it.
The thing to remember is, you can't just take what you're given. You have to question the estimate to complete, you have to compare it with other tasks, and you have to get it to the point where all of you are comfortable with it.PITFALL #1 – Your project is behind!
OK, the unthinkable has happened. Your project is actually behind schedule. Every week, something seems to happen, something quite outside everyone's control. You analyze, advise, reason, plead – and yet here you are, adjusting your deliverable dates once again. And the worst part of it is, deep down you really don't know why or, more importantly, what you can do about it.
Well, there is no need to panic. After all, you can always turn to the wise old Project Manager in the office across the hall who is ready and willing to help you, right? No? Oh well, then, you can always panic.
But before you do, let's figure out what's wrong. There may be myriad reasons why the schedule slips, but some of them are much more likely to occur than others. Broadly speaking, the fault may lie not in our stars, but in:Now let's tackle each problem in turn, starting with the most likely one.
- Our customers. They love to change their minds – all the time!
- Our teammates. They may not be prepared, or may not have "the right stuff."
- Our environment. We may be camouflaged for desert warfare, but find ourselves fighting through the swamp.
- Our selves. In the final analysis, the buck always stops with the Project Manager. So whatever is going wrong – it's probably your fault (at least for not managing it properly!).
Problem: Management shortcomings.
Solution: C3PO said, "It's against my programming to impersonate a Deity!" But many Project Managers try, or feel they ought to. The tough part is that Project Manager's failures tend to disguise themselves as something else. When the Project Manager does not apply the right methodology to requirements gathering, and does not apply the right discipline to documenting its outcome, the result may appear to implicate Customers. When the Project Manager does not set up the right Project Team structure, and does not apply the right discipline to delivering assignments to all team members, the result may appear to imply an incompetent Project Team. When the Project Manager does not select the right technology, or does not secure enough support from the Performing Organization, the result may appear to indicate an unfavorable environment.
But the odds are, when something is going wrong, you should "start with the person in the mirror and ask him to change his ways."Problem: The requirements are not clear, or they are constantly changing.
Solution: Well, it takes no genius to realize that you can't hit a target you can't see or catch. But what can you DO about it? For starters, you need to figure out whether (a) the requirements were not defined clearly from the beginning or (b) the Customers keep changing their minds.
In the first case, you need to hit the brakes hard, and then redirect all resources at your command to re-define the requirements. Go back to the Customers, and re-confirm or figure out what it is they REALLY want. Since the original requirements-gathering process obviously did not work, first you need to analyze the way you went about gathering, defining and documenting the requirements, and try to improve it this time around.
In the second case, you need to have a chat with your Project Sponsor. Explain that by not sticking to their agreement (you do have their signature accepting the requirements, right?) the Customers are jeopardizing the project in all its parameters (Cost, Scope, Schedule and Quality), and, as a result, the Project Sponsor has essentially three options: (1) stop the requirements dithering, (2) expand the Project Budget to accommodate the process (warning: you will still need option 1 eventually!) or (3) cancel the project now (with small overruns) or later (with major overruns).
In either case, change control is key. As soon as you detect an increase in scope, even if you still don't know the full extent of it, you need to start the change control process. Remember that change control is not a bad thing; it's just a process to manage enhancements as well as risks and mistakes. Changes are often unavoidable, as in the case of legislative initiatives or technological advances, and change control serves as a mechanism to assure everyone is aware of and agrees to all deviations from the plan.Problem: Project Team members don't produce.
Solution: First, check to make sure that the fault is not with the environment and/or management. It most probably is. But it just may be possible that your folks do not have the right skills, knowledge or tools to get the job done. Of course, that should be no surprise to you, and you should have had your team training plan going full swing, right? Well, nobody's perfect. The important thing to do is to separate what you can fix from what you can't. For example, if the folks do not have the right tools to do the job – that can be fixed, even if you have to go to the ends of the Earth to get them. Likewise, if the team members do not have the right knowledge – well, that can be fixed too, although by now it may be too late. But if you find that you are stuck with a turkey who just can't do the job, you have a bigger problem. The first thing to do is to try a variety of managerial approaches with the person. Everyone is different, and some people react to certain management styles better than others. But if after deploying your whole managerial repertoire the person still comes up short, the best thing to do is to consult with your manager, or another "seasoned" Project Manager, and understand how such situations have been handled in your organization in the past.Problem: The project environment is not what you expected.
Solution: This problem can take one of two flavors. One, the Performing Organization may not be ready for your project, and is not providing you with the support infrastructure you require. Two, the technology you are trying to utilize is wrong, immature, or not properly implemented.
For the first eventuality, sound the alarms! This is when you need that Organizational Change Management Plan, and your Implementation and Transition Plan. You will need to have another one of those chats with your Project Sponsor. Explain how the team is doing all it can to deliver the product, but the support structure is failing you all around. Make specific suggestions as to what you need, and how it could be accomplished.
For the second eventuality, you must make a quick decision whether the technology can be fixed, or needs to be replaced. Some technological advances sound great in concept, but are just not ready for prime time. Try to avoid "bleeding edge" technologies altogether, but if you do get entangled in one, be ruthless – going back and retracing your steps using an older, less sexy but more stable technology may pay off in productivity gains for the rest of the project, compared with slugging through the immature mire of somebody's half-baked product.PITFALL #2 – You Drop the Issue Ball
In the course of the project, many issues come up. By definition, issues have a potentially adverse impact on the project's CSSQ. Most of them are solved internally, within the Project Team, but some require actions or decisions on the part of other players with whom you may have little influence.
The important fact to remember is that project issues are the Project Manager's responsibility. No matter how clear you are in communicating the issue, no matter how little say you have in its resolution – it remains your responsibility. Identifying another person as a party who can resolve the issue does not abdicate your responsibility to follow it through. Even obtaining consensus that another agency unit should, or a promise that they would, resolve it does not remove your obligation to track the issue to a successful conclusion.
One of the most natural pitfalls is to assume that once you have successfully convinced everyone that someone else has to solve the issue, you are done. On the contrary! Because it is now out of your control, you must be all the more dogged in the pursuit of its resolution. Tell the responsible parties that you're not going away. Keep asking them what you can do to help get the issue resolved, but keep tracking their progress – or lack thereof – on your status reports. Use all the tools in the project Communications Plan to continuously shine light on the issue.PITFALL #3 – You Fall into the Project Black Box
Scene 1 – You employ the latest facilitation techniques to extract all possible requirements from your Customers, even requirements they did not know they had.
Scene 2 – Your team performs wonders to design the perfect product, exactly as the Customers requested, and works like the dickens to develop it exactly as envisioned.
Scene 3 – You beam with pride as you deliver your masterpiece to an eager Customer.
Scene 4 – You slink away in shame as the Customer continues to rant and rave about all the features that the product does not have even though they told you about them all along.
What happened? You "black-boxed" your project. The Customers saw you when you were gathering the requirements. Then you and your team went away into the project black box, and only came out in time to show the Customer the finished product. The problem is, things changed in the interim! The Customer cast of characters may have changed. The business conditions may have changed. The expectations may have changed. And you did not keep in synch. Worse, you did not keep your Customers in synch with your project. You just assumed that because you are giving your Customers exactly what they originally asked for, they would like it. But you know what happens when you assume.
The simple remedy for the black box phenomenon is keeping the Customers involved every step of the way. You should constantly show select Customers project deliverables as they are being developed. Not so they can change their minds but so they know what to expect on delivery. You certainly want to minimize the number of decision-makers who will accept and sign off on your deliverables (chasing signatures of more than a couple of people is a pain) but you want to maximize the number of people who review, or even preview your stuff.PITFALL #4 – You Remain Incommunicado
Once the project really gets going in Project Execution, it is very easy to focus internally – on Project Team dynamics, on technical challenges, on deliverables and schedules – to the exclusion of everything else; yet it is also important to pay attention to the externals. After all, as Project Manager, you are the main link between the project cocoon and the big world outside.
Executing all aspects of your Communications Plan is your responsibility, and nothing is more important than accurate and frequent status reporting. A Project Status Report is the most effective way for all Stakeholders to remain closely connected to and aware of the project's progress – and potential problems.
The two most important questions the Project Status Report must answer are:These questions are far more important to the eventual success of the project, and to minimizing surprises along the way, than the usual dissertations on project status and enumerations of immediate tasks at various levels – not that the status report should not include them. But after collecting, analyzing and evaluating the status information, the Project Manager's job is to make decisions or suggestions regarding changes to be made – if necessary – to keep the project on track.
- What is the latest, best available estimate for the remaining work, and how does it compare with the schedule?
- What issues have come up that may affect the project Cost, Scope, Schedule, or Quality, and what is being done about them?
Of course, the best status report in the world will make no impact if there is no one there to hear it. A regularly scheduled status meeting, attended by as many members of the Project Team as practical, dedicated to a thorough review of the status report, is irreplaceable.PITFALL #5 – You Confuse Desire with Ability
Your customers sincerely want what your project is developing. They demonstrated their desire for it by committing funds to the project; by allocating resources to the Project Team; and by devoting time to meetings, reviews, and other project-related activities. And yet they may be totally unprepared to actually make use of it, or even to implement it at all.
But whose fault do you think it will be when they realize their inability to utilize it? That's right, yours. So it is up to you to make sure that someone determines organizational readiness for the product or service, and that someone prepares for a smooth transition of the product from the Project Team to the Performing Organization. Notice that it does not say you have to do it – just that you have to make sure it gets done. And that requires including in the Project Plan that organizational readiness assessment and transition planning need to be done.PITFALL #6 – They Blinded You with Science (or Technology)
There is no law that says that a Project Manager must be a master of whatever technology the project employs. Nevertheless, you will be called upon to manage numerous technical decisions on the project.
A frequent pitfall in those circumstances is over-delegating those decisions to the more technical members of the team, or accepting the recommendations of your technical experts on blind faith, both of which result in unacceptable loss of control. Instead, make the team explain the issue and alternative solutions to you. As a reasonably intelligent person, you should be able to understand the concepts by listening and asking questions. If, however, the technical folks can't explain to your satisfaction why they are advocating a certain position – watch out! It is indicative of a position dictated more by desire than by reason, or of poor understanding on the part of the supposed experts. Get a second opinion, and trust your own instincts.PITFALL #7 – The Endless Approval Cycle Leads You by the Nose
You thought you were smart. You thought you were ready. You knew how finicky your Customer was, so you built into your schedule not one, not two, but three approval cycles – one for an informal pre-screen, one for a formal review, and the last one for formal approval. You built in time for re-work based on the review. You even indicated in your acceptance parameters that you were only willing to wait so many days for the approval. Yet here you are, a month and a half past the first scheduled deliverable – which your team presented right on time – and you still don't have the proper signatures on the approval form. What happened?
Any of a number of things. You may be stuck in a never-ending fine-tuning cycle (that's like hanging a picture for your mother-in-law: "A little more to the left. No, that's too far! Back a bit to the right. Hmm… How about a little higher? No, that's too high!" etc., etc.) Or you may be chasing signatures in a circle, with every person telling you that he can't sign until the other person does (that's like trying to solve a problem with your PC: "Install an updated driver before we swap the modem" – "No, flash the chip set before we upgrade the driver" – "No, update the operating system first!" – "Looks like you need to replace the motherboard.") Or the exalted Grand Poobah of the Customer tribe may just be too busy to pay any attention to your puny little project.
But the common thread among all the possibilities is that you are just being too darned nice. You may have said that you would only allow five business days for deliverable approval, but what do you do after the five days expire? You may have asked for particular signatures on the approval form, but what do you do if the signatures do not appear?
You fight the approval war on two levels: tactical, and operational. Tactically, you should use two weapons: status report and change control. Highlight the acceptance cycle in your Status Report, and start the change control process when your criteria are not met. Be tough, and insist on the rules being followed. And finally, from the operational perspective, you should just make such a nuisance of yourself that the approvers would sign anything rather than be pestered by you again.
Why should I write a Post-Implementation Report? Who's going to read it, anyway?
Three reasons: because it's good for you, because it's good for your organization, and because it's good for project management everywhere!
Let's say the project did not go well. Do you want to repeat this sorry experience again, or would you rather avoid the same mistakes the next time? The only chance you have is by learning from experience, and allowing your organization to do the same.
Now let's say the project went OK. Don't you want to do better the next time? Enhance your career; earn the respect of your peers, etc., etc.? Repeating what you did right this time will give you more opportunity the next time to concentrate on things you could do better.
Finally, let's say the project was a great success. Aren't you proud of your accomplishment? Don't you want everybody to know about it, and benefit from it?
Last modified: Thursday, 31-May-2007 18:02:51 EDT