There will be other blogs in which I explore specific Project Management methodologies. This post is to give an overview of the project manager’s mantra. There is a difference between someone who manages projects and a project manager and it is NOT the letters after their name. This is also not about the blurring of lines between business analysts, technical folks and certified Project Managers. It is about the real responsibilities of the Project Manager. It is also not about MS Project either or any other tool for that matter.
The three key elements to successful project management are the proactive management and control of Time, Budget and Scope.
Time
It may appear to be the simplest to manage for many. However, any experienced project manager will tell you this is where diplomacy and tact reign supreme. Most people will you give either too short a time line or a timeline that is too cautious. The project manager has to measure duration and placement amongst other tasks to enable the person to qualify their time lines. The balancing of time verses effort is critical to overall success. The project manager must ask each person to confirm that the time line can be met. This gives the person giving the time accountability and buy in at the same time.
When I hear timelines of it should take 2 maybe 3 days, I start to get agitated. This is due to the fact that now people are guessing and that causes the overall project to come under risk due to someone not making a time line. I try to focus the time effort but probing deeper in the effort of how long it will actually take. This becomes easier once you start to know your project team and what they are capable of. You want to tame down the overtime junky and ignite the slow starter.
I also put in clear milestones throughout the project. I use these milestones as checkpoints to allow the slower ones to catch up and the more aggressive ones time to breathe. It also allows the whole team to refocus on the next stages. It is used to define critical paths and inter-dependencies.
Some projects are time sensitive and the end date cannot move. Y2K is an example of this or the move out of a building is another example. These projects I tend to start with the end point in mind and work backwards. Buffer where needed and ensure a sense of urgency is there and of reality based time lines.
Another factor of time that needs to be managed is when your internal resources are also expected to work on other projects or have other work related commitments. This can led to internal struggles and unforeseen delays. The good project manager is working with other project managers or projects to balance the time and effort commitments.
Budget
The one piece that is usually not very flexible. It is great when the budget can be fluid. However, you should not count on getting more money when building your plan.
Capture all the costs for both internal and external resources. Some firms follow the policy of internal resources are factored at no cost. I am not a believer in this model. I also factor in what the opportunity cost is if we lose the internal resources and therefore have to go outside to complete. When your internal resources are working on your project it takes away from the time they could spend on other projects.
Keep a daily, weekly and monthly tab on the costs for each task and the overall costs. Most tools today manage this and as the project manager you need to escalate to higher levels when budget envelopes become strained. Too many projects fail when in the early stages of the project the budget is not kept in check. This can be witnessed if you ever had a home built for you. The foundation guys will allow changes and the money is there and they get paid. By the time the finishing carpenters arrive, the budget is tight and the home owner is left with below expectation results for the budget is not flexible enough at the final stages.
By keeping a tight control of time slippage and scope creep the budget envelope can be manage very effectively. The good project manager knows when to call in the hounds or when to loosen the purse strings.
Scope
Scope creep is the killer of most Information Technology projects. Most IT projects fail for they are unable to maintain budgeted scope and end user expectations. End user expectation is not just at the user requirements stage but throughout the whole project. I am amazed at how IT projects just take for granted the end user knows all the options before them. Once the user starts to get exposed to the final design and starts to implement actual workflow then scope typically is in for a rough ride.
I have spent a large part of my career being parachuted in on bad projects to get them back on line. Two things always seem to surface. The first is taxonomy or the language of the project. I could speak forever on this. What one group uses for a term can surprisingly have a different meaning for another group on the same project. For example what users call a database and what a database administrator call a database typically do not match. The second element I run across is scope creep. The endless features that just have to be there or we can’t go live. Most of these are built as pieces of the project are exposed and people start to kick the tires. This is where leadership verses management comes to play.
First and foremost before you had them sign off on initial scope, make sure the scope document is written in their language and that you have walked them through it from all levels of the team. I have had to rescue major projects because executives allowed line staff to sign off on the scope documents. Their misplaced trust in that adage “they use it therefore they must know” is extremely dangerous. If that was the case why are they not running the organization? Leadership and direction come from above and not from the trenches. The trenches are there to give an acid test to how much impact the project is going to have. You need the input from the entire group but sign off must come from the executive sponsor and that person must understand what they are signing. I love it when I review the project charter and I see technical jargon or diagrams. After I witness this I know I am in for a rough ride.
When death by scope creep seems inevitable, make a list of all the functional requirement of the original scope document and the new list of desired requirements. Demonstrate which functions being asked for are in conflict of the original design points. This usually clears up most issues. Once people are reset for what the goals of the project were it is usually easier to get the train back on the track. The other functions can be placed into latter phases of the project after you have implemented the initial stated phases.
The other thing you need to remind the team about is that scope creep costs both time and money (budget). They need to sign off on change requests. This change process is not just in place for just external resources but also for internal resources as well. You need to get people to agree to the changes and to be held accountable for them. Ensure each change is measured against the original goals and objectives. If there is conflict the project manager has to highlight these conflicts to the senior team. Most projects fail not on one change request but the steady flow of minor changes. Each change must be bringing you closer to your original goals and not away from it.
Lastly, the project manager must not get emotionally involved with the scope, and must report back objectively. This is a challenge for those project managers who also wear the hat of the business analyst.
Like most of the triangles I have mentioned it is about balance of the three sides. When it comes to project management there are so many external forces putting pressure on time, budget and scope that you will have to be diligent, tactful and most importantly capable of making adjustments that enhance and not detract from the project’s stated goals.
No comments:
Post a Comment