| HOME Software Testing Data Mining and Warehousing |
|
Introduction Too many projects start life doomed to failure. Poorly defined business requirements and unrealistic delivery deadlines are all too common. Projects start unraveling from day one with the project manager acting like an innocent bystander to an accident that was waiting to happen. There are many reasons why projects fail, but more often than not an important root cause is in the initial planning process - or rather lack of one. A super project manager knows that putting together a credible and robust plan is one of the foundation stones of effective project management. Although planning is as much an art as it is an exact science, prior experience and common sense both have a big part to play. There are also some sound guiding principles that anyone can pick up and run with. Your planning skills will be called upon from the moment you take over a project. The chances are you'll inherit either an unrealistic plan or nothing concrete at all. Don't be surprised if deadlines and under pinning assumptions delivered in the initial project package are peppered with unfounded optimism. Not all is lost, though, and paradoxically the worse the starting point is, the greater the opportunity for turning things around. Super project managers have to be able to rescue projects in dire straits and in fact they delight in achieving this. The road to recovery starts with building a credible project plan. === Does your project have a spotty past? You're in trouble when: _ The project has changed its name at least once to try to leave its past behind and to restore its good reputation. _ You're the latest in a long succession of project managers. _ Other project managers seem far too pleased that this particular project has fallen to you. _ Your project has already been running for a very long time without delivering anything. === Before we look at what makes a good plan and how to go about producing one, let's start at the point at which things begin to get interesting: the point at which a project is handed to a project manager. Taking on a project For a super project manager, the definition of the start of the project is simply when responsibility is handed over. Most projects will already be up and running in some shape or form when you take over, and in the worst case scenario your new project will already have a spotty past. Even if you join a project relatively early on, it's likely some work will be under way or completed. Perhaps somebody's already recruited a couple of team members ahead of your arrival and they're cracking on with what they see as the immediate priorities. At the start of a new assignment you'll need all your wits about you. Taking on responsibility for a new project is a defining moment for a project manager. There's always a short honeymoon period when it's reasonable to question - in a constructive way - what's gone on before and to recommend corrective action. It's vital to use this initial handover period to best advantage and to carry out a rapid health check. When you uncover shortcomings, you'll also need the skills to get your project back on track as quickly as possible. Although it's impossible to legislate for all handover scenarios, there's a reliable technique for embarking upon a new project with eyes at least partially open, rather than tightly shut. This starts with making sure there's a robust and appropriate project plan in place - and if not, developing one as soon as possible. === A quick project health check: some good starting questions:
===
+++ FACT: Taking over a project that's 'pretty much finished - with just a few loose ends to tidy up' can be the ultimate doomsday scenario. Others can be prone to wishful thinking when assessing what it takes to complete a project. +++ What makes a good plan? The plan captures in one concise document what you've been asked to do and how you intend to deliver. It documents all the key points relating to a project ranging from its objectives and deliverables right through to the key milestones and resource requirements. A good plan is one of the foundation stones for any project and should inspire confidence in all concerned. The mere act of creating a plan is an excellent health check in itself. Producing one is the quickest way for you to diagnose problems and begin addressing them. In a well-defined and properly set-up project this should be a simple process. For projects built on a foundation of sand - and there are plenty of them - this will prove to be a challenging task. An imperfect plan is better than none at all. It's useful to publish a warts-and-all document as an opening gambit even if it has obvious flaws. Your audience can then help you to refine it. This is usually a more productive approach than spending an inordinate amount of time trying to produce something close to perfection first time round. A plan is much more than a schedule The difference between a project plan and a project schedule confuses many project managers. If you ask a random cross-section of them to show you their project plan, most will whip out their schedule - usually in the form of a popular type of bar chart known as a Gantt chart. There's a big difference between these two key documents and what they're used for. A schedule usually lays out project tasks and timings, and perhaps lists important milestones. The schedule enables a project manager to monitor and control progress as work proceeds. A super project plan contains the project schedule, but a lot more besides. The table here shows you what you should expect to find in a plan: [[[ Section Typical contents Overview A summary of the project's key features including its objectives and how to meet them. Objectives and key requirements: A clear description of the project's objectives spelling out what the project needs to achieve to fulfill its business case. Plus a list of the corresponding key requirements that must be met. Approach: A description of how the project is going to be tackled, including the stages it will be broken into and any standards to be adhered to. Major deliverables and key milestones: A summary of the project's outputs and their delivery timescales. Scope: A clear description of the boundary that will be drawn around the scope of the project, identifying the key items that are both inside and outside the scope. Resource needs: A summary of all of the resources that are required to complete the project, broken down by type of resource. Organization/roles and responsibilities: A list of the major project roles, the extent of their responsibilities and how the people resources will be organized. Internal and external dependencies: A list of the project's important dependencies. Some will be within its control, while others will involve third parties. Assumptions: A list of the assumptions that have been used in preparing the project plan. Implementation strategy: A description of how the project deliverables will be put into service. Schedule: A diagrammatic view of major project phases, milestones, activities, tasks and the resources allocated to each task. Risk and issue management: An initial log of the project's key risks and issues, together with how they'll be managed. Quality assurance and control strategy: A description of the processes that will be used to make sure the project's deliverables are fit for purpose. Configuration management: The procedures that will be used to manage the versions of the various project deliverables. ]]] Planning essentials Within the contents of the comprehensive plan we've suggested, there are specific areas that deserve particular attention. These topics represent the foundations of your plan and correspond to the five minimum areas that any plan should address. The rest of this section is devoted to looking at each of these five areas in turn. Although as a project manager you're most likely to be quizzed first about delivery dates! == Some important elements of any good project plan:
== 1 Clarifying project objectives In planning a project, it's essential that the customers have a good understanding of its underlying objectives and the most important requirements. If your customers are not clear about what they want to achieve, your job of putting together a plan is made more difficult. It also raises serious questions about the wisdom of proceeding any further. This might seem an obvious point but it never ceases to amaze us how many projects fail this simple test. At the beginning of a project, you'll often be faced with hazy objectives and requirements. If that's the case, getting these fundamentals clarified must become an important early aim of your project, before it goes any further off track. We're not suggesting that objectives and requirements need to be defined in fine detail from the outset .However we do believe that, before work starts in earnest, it's important for you and your customers to achieve a shared understanding of the 'Big Picture'. So on a construction project, for example, it's a distinct advantage to know whether you're building a bungalow or hotel before starting work on the foundations! It's important to distinguish between a project objective and a project requirement. Objectives describe the desired outcome for the project as a whole; for example, 'to build a house that will be attractive to, and affordable for, first-time buyers'. Requirements, on the other hand, specify what needs to be delivered; for example, 'the house must have two doubles and one single bedroom'. It shouldn't happen to a project manager (but it did) . . . A project manager was assigned to an IT project that had been running for several years. Considerable effort had been devoted to drawing up a complex statement of requirements. The project's major deliverable - for some considerable outlay - was to be the “KEG software system”. Eager to find out more about what lay behind the system, she located the section on objectives in the weighty requirements documentation. It contained one sentence: 'The objective of the KEG project is to deliver the KEG system.' Running a project without a clear understanding of the underlying business objectives is like playing a game of chess without being introduced to the term 'checkmate'. You're going to have trouble finishing the game. It's not unusual to find that customers have developed a detailed view of what they want without giving a great deal of thought to what they'd like the project to achieve. You may even find that some customers see any discussion of the project objectives as stretching beyond your remit: 'Leave the whys and wherefores to me, and just concentrate on delivering what I want.' It's in your own best interests to avoid being swayed by this view. If the project objectives are nailed down, it's easier to help your customers check that the key requirements cross-match and support the objectives. In the final analysis, the project will be measured against the customer's expectations. It's much easier for customers to say, 'This isn't what I asked for,' when they have not been pressed to clarify what they wanted in the first place. Finally , if your customers can't spell out their rationale for the project, it can still proceed - in these circumstances many do and some succeed. However, pinning them down will dramatically increase the odds of a positive outcome. 2 Pinning down the scope All projects need a sound statement of scope. This describes the boundary to be drawn around what the project will and will not deliver. Quite often project sponsors actively want to avoid defining scope too tightly - they feel it will stifle their creativity and limit their ability to flesh out requirements. However, there's a balance that must be struck here and it's important to avoid being too woolly. Having a clear definition of scope doesn't lock anyone into a particular path come-what-may , but it does provide a sound baseline to manage change against. This allows a project manager to make sure everyone understands the impact of scope adjustments and should not be confused with trying to prevent change. This way , the project team is able to identify any extra work required and to agree any additional costs. A clear definition is mutually beneficial. On any project there is a risk of 'scope creep' - the gradual process of the work expanding without the implications being managed effectively. Everyone has personal experience of this phenomenon: ranging from the wildly expensive home improvement project that started life as a quick makeover, to the bank-balance-busting shopping trip that began life as a quest for a single item of work clothing. == FACT: Spell out what's not going to be addressed by the project as well as specifying what is within scope. Don't rely on everyone making the same assumptions about what is 'obviously' implied. == You should also clearly state what's not included in the asking price from day one, rather than finding a difference in expectations after the event, with all the recriminations that will inevitably follow. For example, if your house-building project isn't going to fit out the kitchen, clearly say so from the outset. It's in everyone's best interests to avoid fundamental misunderstandings from the very start. 3 Defining major deliverables No sane person would entertain the idea of engaging a construction company with the simple remit to 'build a house'. At the very least there would have to be a statement of the expected deliverables such as: a three-bedroom house with two bathrooms and a landscaped garden, plus supporting items like architect's drawings and a garden design. This basic principle should be applied to every project - make sure all the tangible things are defined and agreed up front. It shouldn't be hard for you to define your project this way. If this is a difficult task, you'll get a timely warning regarding your lack of understanding about what needs to be delivered. == TIP: Do a sanity check of your major deliverables against your objectives to check they're aligned. Every one should relate directly or indirectly to the project objectives - and vice versa. == The benefits of focusing on deliverables rather than activities can be seen from the very start. A project based on tangible deliverables is far easier to manage. It allows you to be precise about what needs to be delivered and helps you to track progress in a concrete way. 4 Realistic resources Your project sponsor will want to keep a close eye on costs and one of the key questions will be: how much? You'll be under immediate pressure to keep a lid on resources and costs, or perhaps even achieve a reduction. There's certainly nothing wrong with fiscal prudence but this pressure will occasionally border on the farcical. Be wary of demands to reduce costs when the budget is already optimistic or perform other similar acts of financial wizardry. It's important to resist early pressure to adopt an unrealistic budget. While it's unlikely you'll be asked to slash the budget without reason and the argument put forward may be persuasive, be wary of accepting it at face value. For example, the customer may insist, 'We don't want a gold-plated solution.' In reality, this type of discussion is rarely about overly elaborate requirements, it's more about miraculously achieving reduced costs without any consequences. Roughly translated into real project-speak this means: 'We want everything we've asked for but at a discounted cost.' Having got an agreed budget, the first priority for a project manager is to identify and manage those costs that'll be assigned to your project; primarily anything you'll need to buy or hire to build the project's deliverables. This may include the cost of equipment purchased or funds needed to cover the expense of hiring external project team members. Since these costs are a direct result of your project, you'll be expected to prepare an accurate budget for them and then to be held accountable for the expenditure. You can afford to take a more relaxed view of any general overheads that are not directly connected with your project; for example bills for heating and lighting. We're not advocating that a project manager should intentionally ignore known costs but effort spent chasing wider costs is effort lost to other project management tasks. You'll rarely be expected to factor in these costs and doing so only opens up a can of financial worms. Leave well alone! === Key costs to consider when you're preparing your budget: People costs charged to your project including external contractors and consultants.
=== We know it's not easy to deal with a situation where a realistic budget is out of kilter with expectations. In order to defend what might be seen as an unreasonable proposal, you'll need to have a clear audit trail of how cost estimates have been arrived at. This should include a detailed breakdown of how you arrived at the overall cost and high light any key assumptions used. Identifying resource costs for the project plan is just the start of the process. Careful resource planning and management is an important part of super project management. That's why we've dedicated the whole of Section 5 to this topic. 5 An achievable schedule After the handover preliminaries are complete, the first question you'll be asked is, 'When can we see your project plan?' or the project schedule, as we now know it. Primarily your customers will want to know when you expect the project to deliver, but they'll also want some proof your dates were not just plucked out of thin air. It's important to resist the temptation to come up with a crowd pleasing initial offering with wildly optimistic delivery dates. After the warm glow from the backslapping and congratulations fades you'll be left with a millstone round your neck for the remainder of the project. It's far better to set out your stall with a schedule that's realistic and well thought out. You need to understand your customers' timing expectations, but the schedule shouldn't be built around these exclusively. Too many planning exercises are doomed from the beginning because they start from an imposed delivery date and work backwards. In contrast, an awesome plan is based upon three key elements: _ Deliverables - what your project needs to deliver. _ Resources - the resources required to deliver your project. _ Dependencies - those dependencies between your items of work. You should develop the schedule around a clear, logical structure for delivering the project. The first step is to break up the project into manageable chunks of work. For example in a construction project: _ put down the foundations; _ lay the brickwork; _ add the roofing; _ fit the windows, and _ finish off the interior. This structure will usually be based on the major deliverables and it must reflect the sequence of delivery or any interdependencies. It's important that you get the level of detail in the schedule right. The current phase should be sufficiently detailed to enable work to be tracked and reported on at least weekly. However, it will usually be sufficient to have activities for later project phases defined at a higher level of detail. Sufficient planning is required to provide reasonable confidence in the schedule, but a lot of work trying to define distant project activities is unlikely to be the best use of your time. == Top tips for developing a realistic project schedule: 1 Develop a schedule for the complete project. It should include a summary of all of the activities through to the project end. This may not be easy since early project phases may have a significant impact on the rest of the project. However, the schedule without an end is likely to be an accurate prediction: the project will never end. 2 Provide clear visibility of the project's key deliverables. Your schedule should show how and when the project's key deliverables are to be produced. The delivery of each key product should be flagged as a significant project milestone. 3 Design the schedule to make tracking and reporting easy. As the schedule is being developed, make sure it's structured to facilitate progress reporting too. Then you can publish a copy with progress reflected in it or extract the information for inclusion in a report. == Although you're the custodian of the project schedule, it's important to involve your team in its development. This is an excellent way to build commitment to the deadlines. Your project will be at serious risk of derailment if your team believes it's been put together without team members' input. When the going gets tough - which it will - your team might well spend more time finding fault with the schedule than getting on with the job. Lastly, before final publication, commission a peer review from outside the team. There's much to be gained from asking a friendly colleague to run over the schedule with a 'fresh pair of eyes'. Select someone with the right experience who hasn't been involved in the planning process itself to provide an assessment of the schedule's overall completeness, clarity and feasibility. It shouldn't happen to a project manager (but it did) … A project manager joined a project in dire straits - there was no chance of delivering to the agreed milestones. The company's finance director and program manager demanded a new, realistic project plan (schedule) immediately. The project manager built a new schedule based on realistic timescales, using estimates provided by the delivery team. Milestones were tight but achievable. The project team presented its plan and was shocked by the program manager's response: 'Don't ever insult me like this again! I'm going to leave the room for an hour to calm down; I can't trust myself at the moment. When I return make sure your revised dates don't have the same effect.' It's no fun feeling the heat when your schedule is unpopular. But you'll suffer a worse fate if you get bullied into committing to a schedule that's simply unachievable. Summary There's an enormous temptation at the start of a project to roll up your sleeves and get cracking - perhaps to start work on a highly visible, meaty project task and make an immediate impression as a doer. This is just like a builder starting to lay bricks before the architect is consulted. In contrast, when George Washington famously decided to fell a tree, he spent plenty of time sharpening the axe before a quick burst of activity completed his mission. We’re strong advocates of this measured and planned approach. Time set aside for producing a plan is likely to be the best investment you can make on inheriting a project. For a start, never, ever accept your new project is in good shape unless you can see it with your own eyes and prove it with hard facts. Make sure you begin by giving your project an immediate health check by taking a close look at the plan - assuming there is one - and double-checking it's built on solid foundations. Don't be shocked if you discover the plan's in poor shape or non existent. Don't be overly surprised if the objectives aren't clearly stated or if the deliverables are vague and woolly. This type of situation is not as rare as you might think, and it's not the end of the world as long as you take immediate action. Make building a credible plan your top priority. "The art of planning a project..." _ When taking on a project think 'Buyer Beware!' Seize the moment to undertake a comprehensive project review. _ Don't strive for the perfect project plan - but do invest time in resolving any critical issues. _ Put the emphasis on what needs to be delivered - rather than what needs to be done. _ When? How much? Don't be bullied into giving crowd-pleasing commitments that are unachievable. _ Sharpen the ax! Make sure you've got a plan you and your team believe in. == |
| Top of Page | More PM Articles | Prev: The road to super project management | Next: Risk / issue management | Info-Source.us |