Project Execution and Control is where the rubber meets the road. In the immortal words of Yoda, it’s
"Do! Or do not! There is no try."
What are some of the key elements of Project Execution and Control that require the most attention? Not surprisingly, Project Execution and Control has the most pitfalls and the most areas for consideration. The following table identifies processes and tasks which have pitfalls highlighted in this section.
|
|
Process |
Task |
Why is it important? |
|
|
Manage Triple Constraints |
Manage Project Schedule |
Schedule slippage is the most visible sign of a project in trouble. |
|
|
Manage Project Execution |
Manage Issues |
“That malfunctioning little #@?*!, this is all their fault.” Maybe, maybe not. But it’s still your responsibility to make sure the actual problem is fixed. |
|
|
Manage Acceptance of Deliverables |
“Don't be too proud of this technological terror you've constructed.” Your product is only as good as your Customer thinks it is. | |
|
|
Execute Communications Plan |
“Don't get technical with me!” Communicate with your Customers as you would have them communicate with you. | |
|
|
Manage Organizational Change / Manage Product Implementation and Transition |
You may have created the most awesome product in the known universe, but what good is it if the organization is not ready to utilize it? | |
|
|
Manage the Project Team |
“Who's the more foolish... the fool or the fool who follows him?” With some teams, it’s hard to tell who’s leading whom. Don't let that happen to you! |
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:
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!).
Now let’s tackle each problem in turn, starting with the most likely one.
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 man 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 and / or Project Director. 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 (Budget, Scope, Schedule and Quality), and, as a result, the Project Sponsor and / or Project Director has essentially three options:
stop the requirements dithering
expand the Project Budget to accommodate the process (warning: you will still need option 1 eventually!)
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 and / or Project Director. 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.
In the course of the project, many issues come up. By definition, issues have a potentially adverse impact on the project’s Triple Constraints. 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.
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.
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:
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?
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.
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.
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.
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.
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.