Project Planning (High Level) lays the foundation for the rest of the project management lifecycle. In the same way that a faulty foundation will result in an unstable and eventually unusable building, an incomplete or improperly executed Initiation will result in a flawed project.
What are some of the key elements of Project Planning (High Level) that require the most attention? The following table identifies processes and tasks that are highlighted in this section.
|
|
Process |
Task |
Why is it important? |
|
|
Prepare for the Project |
Identify Project Sponsor |
A project without a Project Sponsor is like a ship without a rudder: no matter how sleek the hull or how tall the masts, it just can't get anywhere useful. |
|
|
Conduct Kick-off Meeting |
To continue with a ship metaphor, it’s important to get everybody on board before setting sail! | |
|
|
Develop Project Initiation Plan |
Develop High-Level Schedule |
Can't sail the seven seas without a map! |
|
|
Identify and Document Risks |
Identifying and documenting risks is like putting up lighthouses. Fewer wrecks. | |
|
|
Develop Communications Plan |
Frequent and comprehensive communications is one of the key project success factors. | |
|
|
Confirm Approval to Proceed |
Gain Approval Signature |
Just how far out on the plank are you willing to walk? We thought so... |
In Prepare for the Project, the first imperative is securing a Project Sponsor and/or Project Director. Without the Project Sponsor and/or Project Director to guide and support the project, the Project Manager has an impossible choice of either trying to take on the responsibilities of a Project Sponsor and/or Project Director – for which he/she has no authority, or trying to secure the commitment of unwilling or uninterested executives – over whom he/she has little influence.
Having one Project Sponsor and/or Project Director who is high enough in the organization to be of help, and interested enough in the outcome to be involved, is ideal. However, in many cases, the organization insists on two people – usually managers from two main business functions involved in the project – serving as joint Project Sponsors and or Directors. This situation is not a disaster – unless the managers are severely at odds with each other, especially about what the project ought to accomplish. In most cases, the Project Manager can sit down with the Project Sponsor(s) (as early as possible), and hammer out a common vision of what the project is supposed to do. Some of the useful questions to ask to gain consensus are:
What are we trying to accomplish? What is the desired outcome?
Who will benefit, and in what ways?
Why is the project important to YOU?
How is it going to change the way people do their work?
How will the organization adjust?
However, when the number of Project Sponsors exceeds two, trouble may be afoot. There will be so many more delays getting everyone to the same place, or chasing everyone down, so many more difficulties achieving a consensus, so many more corrections to deliverables, so many more minds to convince, so many more personalities to please. You'd better add lots of time to your schedule for securing necessary approvals!
The effort you will expend in securing an interested, influential Project Sponsor and/or Project Director now will pay dividends throughout the duration of the project. In some organizations, often those with a defined project selection method, projects may only be requested by someone willing to be the Project Sponsor.
The importance of selecting an effective Project Team and writing a comprehensive Project Initiation Plan is self evident and well understood. However, the other key, but frequently overlooked or lightly regarded task in Prepare for the Project is the kick-off meeting. When conducted, the kick-off meeting is often wasted in a pro-forma, listless exercise of bringing unwilling participants together and stultifying them with boring recitations of project objectives, replete with industry buzzwords and technical jargon. Instead, you should look at the kick-off meeting as your opportunity to ignite interest in the project, secure enthusiastic participation in crucial activities later on, and set accurate expectations about what the project is – and is not – likely to accomplish.
How? First of all, the kick-off meeting should be a creative, participatory exercise, involving all attendees. Second, it should emphasize and focus on how the project and its eventual product will benefit each attendee. And third, it should be a showcase for the performing organization’s commitment – and interest – in this project, and your team’s enthusiasm for it.
To make it a creative, joint exercise, you may consider asking the attendees to share ideas on why the project is important and how it will benefit the organization as a whole. To involve self-interest, you may also want to ask participants to explain how the project will benefit each of them specifically, making their jobs better, easier or more fulfilling; and if they can't come up with anything, have the Project Sponsor and/or Project Director make appropriate suggestions. To showcase executive commitment, develop a draft of “talking points” for the Project Sponsor and/or Project Director to use in a statement at the beginning of the kick-off meeting, explaining why the organization is making a significant investment in this project, from both budgetary and human resource standpoints. Finally, this is a great opportunity to showcase yourself and your team, and demonstrate great enthusiasm for the project, which will be contagious and will set the tone for the activities to come.
The task that gives Project Managers the most trouble is coming up with a Project Schedule before the project tasks are well defined and before many important project decisions are made. It is a lucky Project Manager who is not seized by “analysis paralysis” at this stage of the game. How can I commit myself to an estimate (and let's not kid ourselves – the estimate you do put down will become a commitment, which the performing organization will immediately embed in whatever budgetary or strategic plan they are developing) without knowing enough about the project? This paradox is easily resolved if you can estimate as you go along – one process group at a time. Unfortunately, that is a luxury afforded few, if any, Project Managers. The budgeting process demands answers well ahead of the game, and there is no avoiding it.
The one thing that can help at this stage is experience – either personal, or in the form of organizational historical data. If you have been involved in similar projects in the past, you develop a feel for how long things take, and what obstacles – other than product-related – must be overcome and accounted for in the schedule. However, if you are new to project management, to the performing organization, or to the technology, you need to fall back on organizational knowledge. If you are lucky, the organization captured lessons learned from prior projects, and you can find out how long similar efforts have taken. More likely, no such knowledge base exists other than in people’s heads, and your Project Sponsor and/or Project Director can perform an important service in helping identify and recruit Project Managers who may have been involved in similar efforts. Make sure those efforts were actually successful – after all, you do not want to make the same mistake twice. Ask to see their initial and final Project Schedules. If they don’t have either one (or worse, both) move along – anecdotal evidence is of very limited use in real life.
Armed with all applicable knowledge, the moment finally comes to grab a mouse and start scheduling. Most of the time, the end date for the project will be pre-defined by some event outside your control – executive commitment, University Calendar, or some physical constraint. In that case, “backing into” an estimate is eminently reasonable. Walk through the entire project lifecycle backwards, making informed “guesstimates” along the way, and see if you end up at the beginning with today’s date.
|
|
Keep in mind that most early estimates tend to be on the optimistic side, before reality sets in. Consider your first attempt optimistic. Now make a second, more pessimistic attempt, assuming Murphy’s law. This will provide you with the worst-case scenario. The truth is probably somewhere in the middle. |
In other cases, there is a budget limit that must be adhered to. Once again, you can back into your schedule by estimating how many weeks, months or years of effort by a reasonably-sized team the expected budget would support, and from there you can use the industry-standard percentages for product development lifecycles to approximate what your effort is going to be. Decide whether you will schedule according to effort, which is defined as the number of hours, days, or weeks per person, versus duration, which is defined as the number of work days or work weeks per task regardless of number of people. For an area for which you have the most data (or experience), run a “reasonableness” check to see if the estimate makes sense. Finally, you may have a completely blank slate – freedom to commit necessary resources over a reasonable time frame to get the job done in quality fashion. And when you wake up from that pleasant dream, you will go back to the first two options.
But most of all do not obsess over your preliminary schedule (that’s why it’s called “high-level”). Document carefully all your estimating assumptions, and run it by as many experienced and knowledgeable people as you can – not the least, your Project Sponsor and/or Project Director (that’s also why it’s called “high-level”).
The one process that shockingly few organizations engage in despite the fact that it can provide the most “bang for the buck” is risk management, which consists of risk identification, assessment, and mitigation. Notice, there is nothing here that says “risk avoidance.” You can't avoid risk – stuff will happen, and most of it will negatively impact your project, if you let it. What you can do is anticipate it, and be ready with a solution before the problem arrives. Once again, either your own experience, or organizational knowledge (captured as historical data in a repository, or as knowledge in people’s heads) is the key. What obstacles, problems and disasters did other projects run into before? How were they dealt with? What was the impact on the schedule?
Consider every aspect of your project. Ask yourself, what can possibly go wrong? What assumptions are we making that may not be accurate, or consistent? Then, for every risk factor that you identify, you need to determine how it can affect your project.
Another activity that costs very little, but can provide enormous benefits, is communication. In fact, one of the few success factors consistently cited by the majority of lessons learned in analyzing successful projects was frequent and comprehensive communication. Communication keeps all the players in the loop, avoids unpleasant surprises, and builds confidence in project progress and success. Nobody ever complains that they are being told too much, but they usually resent being told too little.
Building an effective Communications Plan starts with accurately accounting for all the players. Don't forget the Project Team, the Project Sponsor(s), all of the Customers, and Stakeholders. Anyone who will be in any way affected by the product or service that your project will develop must be communicated to at some point, and most likely throughout, the project lifecycle. For every player involved, determine how frequently the communication should occur (hint: early and often) and what it should contain (hint: the more the merrier). Of course, make sure it’s OK with your Project Sponsor(s), but if you run into opposition on that front, remind them that even the old Soviet Union did end up discovering glasnost (openness).
Finally, you are all done with Initiation. Your schedule is a work of art. Your Project Initiation Plan inspires masses to commit great deeds. Your Project Plan is correct and complete. You think you are done? Not until you have a signature of someone that matters on a piece of paper that certifies that your opinion of your work is justified, and that you have authorization to proceed to Project Planning (Detail Level).
Remember that unless you are in the highly unusual situation of being your own boss, you do not have the authority to certify your own work, or the clout to commit resources to continue. And unless you want to go very far out on that proverbial limb, you need to have proof that someone with proper authority – most likely, your Project Sponsor and/or Project Director– is on board with what you have done, and what you are about to do.
No matter how happy your Customers and your Project Sponsor and/or Project Director may be with your approach and your schedule, no matter how enthusiastic your Project Team, or your whole department, is with your plans, the only cover that you will have when things go terribly wrong (which, of course, if you've done everything correctly – including getting the approval form – will not happen) is that signature on that piece of paper. So please, do yourself a favor, and get that bulletproof vest before venturing into the shooting gallery known as The Rest of the Project.
Skipping tasks and their documentation in Project Planning (High Level) can cause serious consequences affecting all of the subsequent steps of your project. Project Management (as well as just basic Management) methodologies were developed not because people had nothing better to do with their time, but in response to crises and disasters that resulted precisely from seat-of-the-pants approaches.
