Project Definition Why, What, How? How does a project get started?

How do you know what it is supposed to achieve? How do you know what approach is required? How do you know that it is a good idea in the first place? How will you know if you succeeded? Business needs Project definition Project execution

Before you can effectively manage a project, there needs to be a shared understa nding of that project - its purpose, objectives, scope, sponsorship, funding and mandate. Some people would define the project as not existing until it has an a dequate definition. In the real world, projects often need to get moving while a t least some of these questions remain imperfectly answered. That is particularly true for eProjects. The pace of eBusiness development means that no one will be thanked for slowing the process down by demanding answers t o difficult questions such as "what benefit will you get?" That does not invalid ate the issue - just the response. In an eProject we need to allow for rapid pro ject definition and approval, often with little more than a gut feeling about th e benefit or the way the project will evolve. The Project Manager still needs to consider the issues and ensure there is the necessary degree of sponsorship and authorisation. Much more responsibility will fall upon the Project Manager to k eep track of the evolving initiative and to report back on its potential benefit s, successes, failures and risks. Many organisations have specific processes and standards for requesting and eval uating a project. There will often be norms for assessing the financial benefits , eg payback period, internal rate of return, discounted cash flow etc. There ma y also be standard procedures for presenting a business case and obtaining appro val for the capital investment. Make sure you are aware of any defined standards that apply to you. Project sponsor All projects have sponsors - people who see a need for change and have the autho rity to make something happen. Without them, the project would not have been pro posed. Make sure that you understand who the real sponsors are and check that th ey do have the authority to propose the project and the commitment to make it su cceed. If they are not the right people, you probably need to identify further s ponsors who have that authority and commitment. You need to ensure that the sponsors have enough authority or influence to under take the work and bring about the proposed change in affected parts of the organ isation. For example, a new business solution may not succeed if it is only spon sored by the IT Department and does not have the support of the operational busi ness units. Most often, the best sponsors are from the business - leaders who wa nt to change the way the business operates. As well as the original sponsors, yo u may need to build supporting sponsorship across the organisation and at multip le management levels. A significant project will normally require sponsorship fr

om the organisation's executive level. Such sponsorship is an important tool in Organisational Change Management. The sponsors may have already constructed a good definition of the project and h ave a clear view of what is required. More often, they have an incomplete concep t and no real feeling for how it should be addressed or to what extent it would be beneficial. The Project Manager needs to guide the sponsors throughout the project - they ca nnot be expected necessarily to have a deep understanding of the issues. In part icular, the project needs to be clearly defined before the Project Manager accep ts personal responsibility for its success. Project Definition at project start-up Here are the fundamental things that should be clearly agreed at the commencemen t of a project. They form the basis upon which the project will be defined and m easured. That means they also form the basis upon which the Project Manager will be judged! Mandate Is there a clear, reliable mandate for this project, ie: * Do the sponsors have the power to initiate this project? * Can the sponsors provide all the resources that may be required (funding, people, time, etc)? * Are there other people or bodies (internally or externally) who need to ag ree? Purpose and objectives Is it clear what is the purpose of the project? * Are we able to define clear, measurable objectives that identify what is t o be achieved? * Are the objectives reasonable, achievable and measurable? * Do the sponsors and other stakeholders all understand and agree? Scope What is the scope of the project, for example:

* Is the project addressing the overall business change (ie people, process and technology elements), or just the technology? * Which locations, divisions, departments? * Will there be organisational change - restructuring, revised responsibilit ies, new staff capability requirements, retraining, recruiting, redundancy, etc? Is that organisational change to be seen as a driver for the project or just a consequence to deal with? * Which business processes? Do we wish to change those processes or try to l eave them the same? Is that process change to be seen as a driver for the projec t or just a consequence to deal with? * Which existing processes and systems will be replaced? Which existing proc esses and systems will be retained? Which existing processes and systems will ne ed to interact with the new ones? Is the technology change to be seen as a drive r for the project or just a consequence to deal with? * Should the results be delivered as a single "big bang", or could there be stages or phases of delivery? * Is it clear what other projects or initiatives are in planned or in progre ss that could impact upon this project? Will they compete for resources? Will th ey make our business solution a moving target? Will we require interim solutions ? Benefit At the earliest stages of a project it will be very difficult to establish a solid benefit case for the project. It is still possible to identif

y the types of benefit that are expected. During the project startup, the Projec t Manager will work with the sponsors to define and agree a full model of antici pated benefits. These benefits would not normally be limited to the financial bo ttom line. They would include all types of benefit that are sought - measurable / unquantifiable, financial / non-financial, internally focused / externally foc used. The benefit model would normally be used to justify commencement of the work. Be yond that, it forms an important yardstick against which the project can be asse ssed. It may form: * * * * the basis for change decisions during the project, a way of measuring the anticipated success of the project, the final assessment of the success of the completed project, and a way to monitor the continuing performance of the business function. In what timescale should the benefit be delivered?

Timescales

* Are there specific external requirements for timing, eg new legislation, c ontracts with third parties? * When do we expect to be able to commence? * What is the initial expectation for the duration of the project (and any i ntermediate stages or phases)? * Over what period of time should benefit be assessed for the purposes of pr ioritisation and the benefit case? Control ect? * Who handles day-to-day Project Management? * Which people form the executive control body (eg steering committee) such that they can deliver the full stewardship, decision making, resourcing, and fun ding that is required for or on behalf of the sponsors? * How do these participants expect to participate, eg frequency of meetings, format, formality, reports, minutes etc? Prioritisation, sanity check and permission to proceed Do we definitely agree t o start this project? * Is it truly achievable? Can we get the people, resources, funding, and tec hnology that it will take? * Are the main risks in doing this understood and acceptable? * Is it a good use of the organisation's limited resources when compared to other potential investments? * Is there an absolute commitment from the organisation's leadership that th is project should be initiated and that it will get the degree of support it nee ds to succeed? How will the project be managed and controlled?

* Who has ultimate responsibility, accountability and authority for the proj

Scope Meeting - Available as a PowerPoint97 slide It is important that the Proje ct Definition is fully understood and agreed by all persons concerned. The detai ls should be incorporated into a document which should be formally agreed by the project sponsors and communicated to all interested parties. This document shou ld also provide a good source for communicating the project's definition, purpos e and intended approach to future participants and other stakeholders. Many organisations have a standard name for such a document. You may hear it ref erred to as a "Project Initiation Document" or "Project Charter". In the ePMbook

we will refer to it as the "Project Definition". Project Definition at phase start The Project Definition forms the project's definitive definition and mandate. It is used as a major input to the detailed planning and resourcing that takes pla ce as each phase of work is planned, initiated and mobilised. It is also important that the project's purpose and goals are communicated to th e team members and other participants. They need to understand the value and imp ortance of their work. In most cases it also improves their ability to deliver i f they understand the "big picture". Project Definition during the project Remember that things change. The business changes; customers' needs move on; dep artments are restructured; there may be mergers and acquisitions; there may be d emands to cut costs or drive change faster. At any time when the project's purpo se might be challenged or the anticipated outcome is significantly changed, the Project Definition should be re-examined to see in what ways it has changed or s hould be changed to reflect the new circumstances. Where this has an impact on t he benefit case, approach, planning, timing, resourcing, or expected outcome, th e Project Manager will need to review and re-calculate the detailed changes and present a revised definition for agreement by the project's sponsors and executi ve leaders. Project Definition at phase end Phase end is a good time to measure the success of the project to date. See how well the project's original ambitions are being adhered to and how the anticipat ed benefit matches up to the original definition. Report back successes, failure s and revised expectations to the project sponsors and executive. Give that feed back to the team as well so that they understand how well they are performing an d how valuable their work has been. Where there has been some significant departure from the original intentions, th e Project Manager should investigate, review, analyse and report these conclusio ns to the project sponsors and executive team, along with any specific recommend ations or planning revisions. As ever, the guiding principle should be to obtain the optimum benefit for the organisation. Project Definition at project end In all good projects, the leadership and participants take time to reflect upon successes and failures. In particular, it is important to determine whether the defined project was successfully completed - both in terms of the most recent de finition and against the original intentions. There are several reasons for this : * to determine whether the work is really finished or whether further action is required * to consider whether further initiatives should be defined to build upon th e success of the project * to show that benefit has been achieved and that the project will generate value * so that the success can be communicated both within the organisation and t

o external parties such as customers, investors, suppliers etc * for the organisation to learn lessons about this type of business initiati ve * for the individuals to learn lessons about their strengths and weaknesses, and to identify successful approaches to their work.

Planning Why, What, How? Planning a project is where the Project Manager must bring together the complete understanding of the project's requirements with a deep understanding of all th e elements that are required to conduct a successful project. In many ways, it i s the centrepiece for the Project Manager's skills. Of course, it all counts for nothing unless it leads to a successful project! Planning, estimating & resourcing - available as a PowerPoint slidePlanning, est imating and resourcing may be viewed as separate issues, but they need to be con ducted in parallel as they directly affect each other. * Planning is the definition of work to be done, including resource requirem ents, dependencies and timing. * Estimating is the calculation of the amount of time and effort that will b e required per type of resource for each part of the work to be done. * Resourcing is the allocation of actual resources (usually the project's wo rkforce) to the plan. The availability of resources will always be limited. Resources may be required in greater quantities than are available or have competing demands on their time . It may be necessary to make compromises or move work between different potenti al resources to make best use of the resources available. As these practical adj ustments are made, there will inevitably be an impact on the duration and timing of tasks. It may also affect the project's predicted costs. Here are some of the key issues in deciding what approach to take: * * * * * * top down or bottom up? all in one go or exploding detail in stages? fully detailed or streamlined / summary? one plan or several sub-plans? automated scheduling or manual scheduling? activity, process, deliverable, outcome, or milestone-focused?

Top down or bottom up?

The classic approach to planning is top-down. We divide all the things required into a few high-level items then, explode them into greater levels of detail as the planning process proceeds. Very often this explosion stops at a relatively h igh/summary level of detail for the initial planning and is only expanded into f ull detail shortly before each new phase of work. Top-down is the most logical way of thinking about a project and is usually the best approach to new endeavours. It provides an early high-level plan, including initial costs and timings, which can be used in the project's definition and be nefit case. Bottom-up planning makes sense where we already have a good example of a success ful similar project plan to base the new project on. A majority of projects will be similar to something that has been done before and it makes sense to use tha t as a starting point (assuming it was of good quality). As well as saving time in the planning process, this allows us to learn lessons from the previous exper iences. In particular, estimates can often be extrapolated from the previous pro jects. In bottom-up planning we start with the full detail of a previous plan and adjus t the precise details, estimates and dependencies to be correct for the new proj ect. From the beginning, we have a fully detailed plan. This usually means that where top-down plans need to be exploded, bottom-up plans need to be summarised so that they can also be used at a summary level for things like the project def inition, benefit case, and reporting. All in one go or exploding detail in stages? Where you have started from a detailed plan and worked bottom-up, you already ha ve the full detail - but remember to review that detail as you progress through the project as things will inevitably change. You may choose to review the detai l in stages in a similar manner to the way you would deal with a top-down plan. If you started with a top-down plan, the question is - when should you explode i t into full detail? If it is a relatively simple project, with short timescales and a manageable number of resources, you may easily be able to generate a suffi ciently detailed plan at the beginning of the project and stick with it (bearing in mind that the Project Manager has a continuous duty to make sure the plan is realistic). In larger projects, best practice is to explode the detail in stages. Here are s ome of the reasons why: * No one needs to know precise details so far in advance that it is of no co nsequence. * Giving precise detail too far in advance inevitably means it will be wrong - some of the people reading the plan will not realise that and those that do m ay think you are stupid for being so accurate. * You have more important things to be doing with your time during the defin ition and launch of a project than worrying about the precise timing of events i n the distant future. Clearly, you need that detail far enough in advance to make decisions about the allocation of individual people to tasks and to mobilise the resources required. You should also plan out the detail for logically complete elements of the proj ect together so that all related issues are examined together. Very often this means that detailed plans are best prepared per phase during the

project. The first phase of work would be planned immediately following the pro ject definition. Further planning for following phases would be done towards the end of each phase to give a reliable base for the starting dates and any variat ions in the originally planned activities. It must, however, be done early enoug h that the required resources can be identified and mobilised in time for work t o commence. Fully detailed or streamlined / summary? Here lies maybe the biggest area of disagreement between those involved in proje ct management. Arguments range from the senior executive's view of a plan - must fit on one page of a flipchart - to those managers who wish to consider the ful l detail of every task conducted by every person. To put that into numbers, shou ld the plan have ten lines or ten thousand? Do not confuse the level of detail you need for project definition and status re porting with the level you need to use to assign individual people to individual tasks and track their progress. The full detail is rarely appropriate for anyon e except the Project Manager and the Project Office team. The project sponsors a nd other concerned parties will only want to see key summary information such as milestones and overall costs. Project Team members only need to see the full de tail where it is related to their own activities. Given that the full detail is largely for the Project Manager's benefit - how do you make that choice? Here are some of the factors to consider: Factor Small plan Large plan Constructing the plan Low effort / short time High effort / long time Identifying dependencies Will be at a high level hence may be inefficienc ies and missing links Can be fine tuned for perfect automatic scheduling Identifying resources Probably need to assign groups of people to deliver high -level tasks collectively Can accurately assign individual people to indiv idual tasks Telling people what to do Probably insufficient detail - you will be relyi ng on "word of mouth" Should all be in the plan Tracking progress Low effort but possibility of issues being hidden High effort - but accurate Reporting progress May be usable without summarisation Will need to be summarised for reporting purposes

It is hard to judge the optimum approach. Very often it will be dictated by norm s within your organisation, or maybe by previous plans that you are using as a s tarting point. Strangely, perceptions do not vary significantly with the size an d complexity of the project. In general, people seem to be: * concerned at a lack of analysis in detailed plans that fit on one page, * comfortable with plans around 200-300 lines * disconcerted by plans over 1000 lines, and * convinced the Project Manager is crazy, obsessive and impractical if the p lan is over 10,000. Unfortunately, that generalisation is not fully reliable. The key advice is to g et your strategy agreed with the project sponsors and others concerned! One plan or several sub-plans? A good way to deal with complexity and with unwieldy large plans is to use a num

ber of sub-plans. There will be one overall plan showing the whole project, but for its detail it will link to various sub-plans. The sub-plans would deal with various subsets of the overall project, for example, there might be one per work stream or one per sub-team. Ideally, each sub-plan will have its own Team Leader . That Team Leader will have responsibility for delivering against the sub-plan and would often be given the job of developing the detail during the planning st ages. The Project Manager will need to consolidate the plans for the overall estimatin g and scheduling of the project. Particular attention should be given to issues between the sub-plans, for example: * identifying and working to overall project milestones, * cross dependencies, * scheduling and contention when the same resources are used in more than on e sub-plan, * ensuring compatibility and standards. The ease with which the project can be handled as a number of sub-plans often de pends on the choice of automated project planning tools. The best (ie most expen sive) tools will have no trouble consolidating and scheduling multiple plans. So me of the more basic software tools have limitations that might lead the Project Manager to prefer to represent the sub-plans as separate sections within a sing le physical plan. Automated scheduling or manual scheduling? Almost all project planning tools provide automated scheduling - so why would yo u not want to use it? There are two main issues that you need to consider: * To obtain good results from automated scheduling, your planning informatio n needs to be mathematically and logically perfect. All dependencies must be cor rectly stated. All resources need to be identified along with accurate effort es timates. Detailed allocation of people to tasks cannot be assumed - the plan wil l need the full detail. Resource availability needs to be correctly held. Workin g days need to be defined (eg let's not schedule people for public holidays). * The capability of project planning tools to provide good results varies no ticeably between different tools. Some tools provide limited support to spread t eam members' work to keep them fully occupied and to make optimum progress. For example, if the plan says the Project Manager is required one hour a week for "P rogress Meetings" and full time for five days on "Project Definition", some tool s may conclude that "Project Definition" cannot start for 12 months until all th e scheduled "Progress Meetings" have been completed since there is no time befor e that when the Project Manager is available full time. Tools are often poor at things like repeating, periodic tasks or scheduling tasks on a day-by-day basis to use up all available effort - particularly if it means there could be gaps wi thin the task when no work is done. Given the limitations and idiosyncrasies of the various tools coupled with the l ogical complexity of Critical Path Analysis and resource optimisation, the Proje ct Manager will normally have to put considerable effort into teasing the plan u ntil the automated scheduling gives good results. It would be wonderful if the t ool could do "what-if" analysis and try all the tricks in the trade to suggest a good resolution like "did you think of getting an extra programmer - that would halve the length of the project", or maybe "the optimum number of programmers i s 3.6 FTE". The sort of information the Project Manager may need to adjust is:

* imply * oject * * or as

adding or changing dependencies (often with no logical justification but s because the plan works better in that sequence) adding in arbitrary timing lags (or negative lags) so that areas of the pr start 'around the right time' priorities per task whether tasks not on the critical path should be done as soon as possible late as possible.

Try to avoid manipulating the plan by locking in specific dates - unless they ge nuinely are fixed dates. You will almost always have problems when re-scheduling the plan if some of the dates are considered immovable. Simple tests of good scheduling are: * resources are occupied full time on almost all days, * there is no major gap in a path or workstream unless, and * of course, the earliest achievable end date. Automated scheduling can be seen as an investment. It can take a huge effort to get the plan fine-tuned to the extent that you can rely on it, but, once it is d one, the plan can be re-scheduled as often as desired with very little effort. A s well as adjusting the plan during the project, this allows you to perform "wha t-if" analysis during the planning stages (eg "what is the quickest we could do this with unlimited resources?", "how much quicker would it be with one addition al programmer?", "how many programmers do I need to meet the required completion date?"). The problem with automated scheduling is the time and effort that needs to be in vested to get a good model. Not surprisingly, many Project Managers feel they ca nnot afford that time. Others try it and find things are not working out - so th ey give up and lock in manual dates instead. Manual scheduling is probably the more common approach in reality. It can be jus tified on the basis that progress is more important than accuracy and optimum pe rformance. If you intend to schedule the plan manually, remember these things: * check that you have allowed for the real dependencies within the project ( eg we cannot train the users until there is a working system available) * check resources are not unrealistically loaded (team members rarely work m ore than 24 hours in one day) We discuss scheduling the detailed plan below. Activity, process, deliverable, outcome, or milestone-focused? Here is an esoteric debate for Project Managers to discuss over beers in the eve ning. The question is - how do we define the 'things' in the plan - what are the y? Let's take a look at several philosophies: activity, process, deliverable, ou tcome, and milestone. The classic and common understanding is that a plan tells you what things to do. It describes the various activities that are required. These would typically be broken down and structured into categories for ease of understanding. This is a basic concept in Project Management - the Work Breakdown Structure (WBS). Here is a very typical example structure of an activity-focused plan: Logical Structure Example Phase 1 Phase 1 - Define the Project

Activity 1 Define Project Scope

Task A

Define Scope

Task B

Agree Scope Activity 2 Prepare Benefit Case Task C Construct Benefit Case Task D Agree Benefit Case Note that because we are talking about activities and tasks we are using verbs action expressions. In fact the typical construction is in the form verb + noun ie "do the thing". A variation of this is to use a process focus for the structure of the plan, but , probably, leave the low-level tasks and deliverables at the same level. Proces s focus is following the evolution in thinking that occurred in analysing busine ss processes - except here applied to the processes of a project. The intention is to tell the story of each process within the project rather than present it i n a disjointed way divided up into phases. For example, one section of the plan would describe the story of testing. It would start with the early definition of the project's approach to testing, through the detailed planning, testing prepa ration, conducting tests and gaining business acceptance. As well as telling the story in a way that is easier to understand, the process focus generally fits i n with the idea that projects can be organised into various workstreams, each de aling with a layer of the overall business solution. Here is a very typical example structure of a process-focused plan: Logical Structure Example Process 1 Delivering the project's objectives Sub-process 1 Managing scope

Task A

Define Scope

Task B

[all further tasks dealing with scope] Sub-process 2 Delivering optimum benefit Task C Construct Benefit Case Task D [all further tasks dealing with benefit] The problem with a process focus is that it offends those Project Managers and P roject Sponsors who expect the plan to be organised in distinct stages. For exam ple, the testing process will start early in the project when the overall approa ch to testing is agreed; test planning and preparation will occur in the middle; test execution and sign-off occur towards the end. To place all these together might tell a good story - but it challenges the common belief that project plans should be organised to show logical and/or time progression. Within each proces s, such staging may be apparent, but in a single view it is hard to present both the staging across processes and the story of each process. You will probably hear some "rules of thumb" about how tasks should be defined, for example, tasks should not be so long that progress cannot be tracked regular ly or so short that they are trivial - some people would suggest five days is a good length. The problem here is that some very important things such as a "sign off" might be very short in duration but vital to the good conduct of the proje ct and others like "track progress" might be very long tasks with no merit in su b-dividing them or measuring interim progress. One common recommendation about defining tasks is that all tasks should have a m easurable output that clearly evidences the task is successfully completed and w hich represents the main purpose of the task. For example, "Define Scope" might produce a deliverable called "Scope Definition". This leads some Project Managers to suggest that the entire approach might be be tter if everyone focused not on doing tasks but on delivering the results - henc e the project plan could be expressed as deliverables and sub-deliverables. For example, in a deliverable-focused plan the previous examples might look like this: Logical Structure Example Phase 1 Phase 1 - Project Definition

Major Deliverable 1 Project Scope

Deliverable A

Scope Definition

Deliverable B

Scope sign off document Major Deliverable 2 Benefit Case Deliverable C Benefit Case Deliverable D Benefit Case sign off document Because the plan is now expressed in terms of its deliverables, the expressions have now become nouns - they are the names of the main deliverables being produc ed. We can see in this example a strange possible consequence - the focus is now on producing something called a "sign off" document. One thing a deliverable focus can do for you is to generate a large number of small, new, highly-important doc uments which serve as visible deliverables for something that is harder to see, for example, agreement. Alternatively, some Project Mangers would happily have referred to that final ou tput as the "Agreed Benefit Case". This too can work, but it poses the problem t hat something which is logically the same thing can have a different name becaus e its status has changed. As well as the philosophical and semantic debates, thi s can lead to practical difficulties when tracking deliverable flow and particul arly when using an automated document management system. Maybe the biggest problem with deliverables focus is more one of usage than inte nt. Project Managers tend to look for some form of visible document that shows t hey have completed the deliverable. For example, which of these outcomes do you think a Project Manager is more likely to describe as a deliverable: * a trained workforce capable of operating the new system, or * a training manual?

Unfortunately, deliverable focus in practice often emphasizes the reports and do cuments that are to be created and diverts attention from the true desired outco me of the work. The project might appear successful because training materials w ere produced ignoring whether or not that training had the desired effect on the workforce. So, to take the argument to its conclusion, the thing most worthy of the Project Manager's attention is not the work done, nor the reports produced, but achievi ng the desired outcome in the most beneficial manner. There is no doubt that thi s is a good ambition for the Project Manager. The question is - should the plan be expressed in those terms so that everyone is focused on the outcomes? Here is a final look at an example structure - this time outcome-focused: Logical Structure Example Phase 1 Phase 1 - Project Defined Major Deliverable 1 Project Scope

Deliverable A

Scope Proposed

Deliverable B

Scope Agreed Major Deliverable 2 Benefit Case Deliverable C Benefits Defined Deliverable D Benefit Case Agreed Now the work is described as outcomes. These might be expressed as statements li ke "Benefits Case Understood and Agreed by All Parties" - except you could short en that to "Benefit Case Agreed" for the sake of brevity on the plan. In any of these approaches, or instead of these approaches, you may identify cri tical checkpoints indicating the completion of a significant achievement, delive rable, stage of work etc. These "milestones" are inserted into the plan as contr ol points for management and reporting. They often represent important review po ints or interdependencies in the plan. In high-level planning, it may be appropr iate to start from a network plan only showing milestones and their dependencies

. Where this works well, it is usually because the milestones in fact represent deliverables or outcomes - so maybe a deliverable or outcome view would have wor ked better. There are things to be said for and against all five of these styles. Here is a quick summary: For Against Activity focused It's what many people are familiar with - instructions t hat tell them what they have to do Can seem like a lot of work is done with out creating any tangible, measurable result Process focused Very good at explaining how things are done Loses th e staged view of the overall project Deliverable focused Focuses attention on delivering the deliverable Might focus attention on trivial or artificial outputs instead of the major focu s of the work Outcome focused Focuses attention on what really counts Can seem esoteric and can be hard to measure that the outcome has been satisfactorily ac hieved. Milestone focused Presents a simple picture focusing on critical informati on. In reality is focused on deliverables or outcomes as described above. Wi ll not normally focus attention on the path or effort to attain each milestones. An ideal approach would be to hold all these differing views and criteria in a m ulti-dimensional model of the project whereby the Project Manager can view and p resent the plan in any of these manners. Unfortunately the workload to create an d manage plans would be high if not prohibitive and the software tools do not ex ist to make it possible. A good plan will, nevertheless, be organised so that th e major activities, workstreams, deliverables and outcomes are all apparent to t he reader whichever main structure has been chosen. Initial planning during Project Start The earliest planning overlaps with Project Definition. It is necessary to have some view about the project's approach, timescales, work effort and costs to be able to perform the initial Cost Benefit Analysis and justification. Following that, the project would normally be planned at level of detail. This management-level plan defines all tion of the project. By this stage, the structure of the ear. Phases, major deliverables, activities, workstreams nes will be defined. The "shape" of the project Projects can have any number of different shapes. By shape we mean the way the d ifferent elements are structured and how they relate to each other. An IT strate gy project does not look like an eCommerce project, which, in turn, does not loo k like an ERP package implementation. It is more than just a question of what we are trying to achieve - it is also a question of how we will go about it. How d o you explain the shape of a project? Where you plan to use a predetermined methodology for the work, the shape will b e defined by that methodology. For example: * Does it do it in three phases, four phases, five, six seven, eight? * What is the size of each phase? * Does it have waterfall phases, overlapping phases or iterative phases? a summary or management major work for the dura work will need to be cl and significant milesto

Alternatively, you may find you are free to make these choices for yourself. Her e are some of the issues: Waterfall? The waterfall style is the classic approach to projects and is still very popula r - particularly in the public sector. In a waterfall, each phase forms a major segment of the work which finishes and is approved before the next one starts. I t is called a waterfall because it looks like a waterfall. Waterfall - available as a PowerPoint97 slide It is easy to see the problem with the waterfall - it tends to make poor use of time. Typically each phase comes to a halt, then there are some time-consuming r eview processes, then people start working again. Consider too the way that work naturally takes time to build up at the beginning and how the final few issues take time to resolve. Altogether, this leads to poor use of resources. Poor use of time with a waterfall approach - available as a PowerPoint97 slide Project Managers often use a simple approach to detailed dependencies. They appl y waterfall logic to detailed activities and tasks as well as to the major phase s. The same inefficiencies will apply, albeit on a smaller scale. Overlapping phases? To avoid the inefficiencies of waterfall logic, you can seek legitimate ways to overlap the phases. By legitimate, we mean it must not significantly increase ri sk (although the deliberate acceptance of risk to achieve faster or cheaper resu lts can be a legitimate business decision if properly assessed and agreed). The reason for those review points in the waterfall is that it is generally unsa fe to proceed to the next stage of work, building upon the previous one, if we a re uncertain that the starting point is valid. Case Study A third party software house was building new systems for their client. Pressuri sed by obligations to meet time and cost targets, the software house had pressed on with the programming of the new system and were nearly finished. At the same time, the design documentation was still held up at the sign-off stage. It had not yet been finalised and agreed. Our review of the project found the reason why. The design was not what the clie nt organisation wanted. It was not a question of minor corrections - it was the wrong solution. All the development work had been wasted. There are ways you can plan to overlap phases, activities and tasks in a safer w ay to make best use of the projects resources. In general you need to have secur ed firm commitment to various issues before the "phase end" signoff process. For example, you might agree the hardware architecture during the conceptual design work - so you could acquire and install the equipment needed for development im mediately to avoid delays. Here are a few other examples: * If you are using packaged software, most architectural and technical detai ls will be predetermined by that choice of software. This means you can normally work on different aspects of the overall business solution as separate streams

of work. * Design and development components may be reviewed and agreed initially as free-standing aspects of the overall solution, provided that the overall solutio n itself is thought through in advance and reviewed at the end. * Team members should have more than one aspect to work on, so progress coul d continue while any specific component is being reviewed. * Documentation can be drafted in parallel with design and development tasks - provided it is not finalised until the detail has been fixed and agreed. * Training materials can be prepared based on partly complete design informa tion provided they will be reviewed and completed based on the actual final desi gn. Iteration Many rapid approaches to applications development rely on an iterative approach. Parts of the project plan will repeat until the overall job is completed. this allows progress to be made in easy stages. There are two main forms of iteration : * homes * to be repeating design, prototype construction and review so that the solution " in" towards the best solution for the business needs, releasing components for live usage without waiting for the full solution completed.

Iterative approaches are particularly appropriate for eProjects due to: * the imperative to deliver rapid benefit, * the rapidly changing technology and business drivers, and * the difficulty of defining requirements accurately without building protot ypes. Here is a high-level example of iteration at work: Iterative Approach - available as a PowerPoint97 file The iteration may have multiple layers. In effect, the example above has two lev els of iteration - multiple releases comprised of repeating prototyping loops bu ilding up to each release. In simple cases the prototyping could be seen as a co ntinuous process. It is only where it needs to go through baseline stages that t he planning becomes complex. Baselined iterative approach - avaiable as a PowerPoint97 slide Project Managers find it difficult to plan for iterative or replicated processes . Just how many loops are there going to be? Do we assume a certain number of de sign loops and delivery stages? Here is the Project Manager's nightmare scenario : * Project delivers major areas of functionality in separate stages * Stages are rolled out into separate locations * Each stage contains separate business process streams dealing with major c omponents of the business solution * Iterative design prototyping is organized in cycles * Each cycle addresses various sub-streams or collections of design topics Replication within replication within replication within replication within repl ication...

Explaining the shape of a project Probably the easiest way to explain the shape of your project is using a graphic al presentation. Let's start by looking at an example. Study this carefully and see if you can deduce all the messages it is trying to communicate before lookin g at the explanations. Example Project Shapes - available in PowerPoint97 Here's what we were trying to say: * There are seven logical, overlapping phases (it is not a waterfall) * There are three main stages - agreeing the conceptual design, building the solution, and operating that solution. * key reviews would be held to decide whether to proceed * The first stage delivers a conceptual design * Early focus is on defining and agreeing the vision for this undertaking. T hese thoughts continue to evolve up to the finalisation of the conceptual design . * Once the initial vision is substantially in place, attention then moves to defining how the project should achieve it. * In turn, as this becomes clear, work increasingly focuses on producing the overall conceptual design. * The second major stage delivers the working solution. It is a much larger amount of work and a longer timescale. * An iterative prototyping approach will be used, so design work and develop ment work are interlocked * Around "live date" the final formal testing and acceptance will take place . * At the same time, the project team and user community is preparing intensi vely for implementation and live running. * We are also building up for routine operation, maintenance, support and en hancement.

Here are some of the graphical techniques we use: Meaning Graphic Small phase Big phase Overlapping phases Interlocked phases Increasing focus Initial major focus which then diminishes Phase which builds up then tails off Iteration Detailed planning for the phase Before the start of each phase, the initial high-level planning needs to be expa nded into fully detailed plans with the chosen depth of detail. Unless you chose the bottom-up "big bang" approach to planning and started with a fully detailed plan, there will be considerable effort involved. Even where the original plan was created at a detailed level, it should now be reviewed and revised to take a ccount of the current starting position and any changed circumstances. As we noted in general, planning is always linked to estimating and resourcing. All these details must be combined to calculate a detailed schedule of work. Wit h good planning tools, a well thought-out Work Breakdown Structure (WBS), milest

ones, careful recording of dependencies, effort and resource allocation you shou ld be able to calculate the detailed schedule automatically. Gantt charts and CPM or PERT charts The two main formats for preparing a plan are the Gantt chart and CPM or PERT ch art. Gantt charts are the most popular as they present an simple picture of the work and make it easy to see when things start, how long they are and how they a re sequenced. They are particularly helpful in communicating the plan to people unfamiliar with Project Management. The Gantt chart represents each piece of wor k as a bar on a chart with a horizontal scale to show dates. Gantt chart Some Project Managers believe that a PERT (Project Evaluation and Review Techniq ue) chart or CPM (Critical Path Method) network is a more scientific way to thin k about a project. The PERT chart makes you think in detail about the logic and dependencies of a project. The logic and mathematics behind PERT and CPM are not subjects for the ePMbook. The good news for the practical Project Manager, as o pposed to the academic, is that you can leave the detailed calculation to your p lanning tool. In these forms of analysis, the plan is normally depicted as a net work of boxes for work items with their dependencies shown as links. CPM network This depiction shows the logic behind the sequencing. It also helps us to calcul ate the "Critical Path" - ie which path through the work network takes the longe st and therefore defines the elapsed time that will be taken. In both the exampl es, the Critical Path is shown in red. Note that this particular style of diagram is not very good at telling us about the nature of the dependencies. As you saw in the Gantt chart, the various piece s of work deliberately overlap, eg we can start looking at benefits before the s cope has been fully defined. In fact, it has "Start-Start" dependencies and "Fin ish-Finish" dependencies as well as the traditional "Finish-Start" links. In som e styles of chart, this would be made more clear, for example, by showing the co nnecting line going to the end of the box if it means "Finish" or the start of t he box if it means "Start". Another problem with PERT/CPM charts at a detailed level is that they can look a s complicated as the wiring diagram for a space shuttle. Imagine say 2000 boxes each with an average of 2 dependencies, some of which jump between major section s of the plan. Even if you have enough wall space, it is hard to imagine how you could comprehend it. In fact, the best way to use these networks is to view the m in whatever logical sequence you wish through the planning tool. It should let you follow a train of logic such that you can comprehend how it works or what h as gone wrong. With modern planning tools, this debate between Gantt and PERT/CPM is much less of an issue since you can view the project plan in many different ways including traditional Gantt and PERT/CPM styles. Some tools can combine these views, alon g with many other bits of information, into a single view. See how the Start-Sta rt and Finish-Finish dependencies are shown clearly in this standard view from M icrosoft Project 98. MS Project 98 Gantt chart - bigger version available Dependency types Most Project Managers and planning tools assume that the default dependency betw

een two tasks is "Finish-Start" - ie you must finish (completely) the prior task before you are allowed to start the next one. Most plans are expressed in this way. Conversely, most people conducting the work ignore this and take a more pra gmatic approach to make good use of their time. Very often, the true nature of the dependency is more subtle: Dependency Use Examples Finish-Start Successor really cannot start until the predecessor is completed Agreement is absolute requirement - eg don't start until you have a cont ract Physically impossible - eg must have a working computer system to do the develop ment work Finish-Finish You could reasonably make progress on the successor but you cann ot finalise and agree it until the predecessor is safely completed Start bu ilding a prototype based on the proposed design - but you cannot finish building until the design is fixed. Preparing a training course could be done in parallel with development and testi ng work - but it cannot be finished and validated until the final design is fixe d and the training environment is ready. Start-Start You cannot start the successor without at least some output from the predecessor - but you don't need to wait for it to finish You can document and review fact-finding interviews as soon as you have started the first one As soon as the testing starts the control and incident management process should start Start-Finish The successor cannot finish until the predecessor has started Unusual logic to use! Many real-life dependencies have both Start-Start and Finish-Finish components. Take the simple example of documentation. You can start documenting as soon as y ou start to define the thing it refers to, but you cannot finish it until that t hing is fully and irrevocably defined. When defining dependencies you may also wish to stipulate time delays. In some c ases you can build in genuine estimated delays. In some cases, a Project Manager may use arbitrary lags to help with the scheduling and sequencing or to allow f or contingency. You might also use a negative lag where you are saying you wish to schedule something in advance. Here are some examples: * wait three weeks for vendors to respond to your tender (Finish-Start with three week lag) * wait four weeks after requisition for the hardware to arrive (Finish-Start with four week lag) * it will take at least two more days to get the final interviews documented and reviewed (Finish-Finish with two day lag) * we want to order the hardware six weeks before it is required for the star t of development (Start-Start with minus six week lag) Milestones Milestones are useful tools in planning and scheduling. They may have been used at a high-level to present the overall project plan. Alternatively, they may be used tactically to identify completion of significant achievements, identify cro ss-dependencies, then subsequently provide a control and reporting mechanism dur ing the project. Milestones do not normally have work attached to them. They simply record in the

plan that a specific logical stage or accomplishment. In this example, "User Readiness Confirmed" is not itself a piece of work or a d eliverable - it is the state we have achieved when all the individual readiness checks have been satisfactorily completed. Scheduling We discussed earlier some of the considerations when deciding how to go about sc heduling. Let's now look at some of the detail. The basic things we need to identify are: * when does a piece of work start, and * how long does it take? When it starts will be calculated primarily by its predecessor dependencies, plu s the need to smooth out the usage of resources. Planning tools normally include complex logic to calculate the optimum schedule - but, as we discussed earlier, they it may take some manipulation to give optimum results. You can often tell whether a plan was scheduled automatically simply by its appearance. Automatic s cheduling often appears crazy but gives optimum results. Manual scheduling looks far too neat and orderly to have been calculated by a computer. How long it takes can be calculated as: Duration = required effort / resources applied The thing that makes this sometimes difficult is that there are three variables: duration, effort and resource. It is a three way balance that you have to achie ve. Here are some examples: If we are estimating the duration of a task to type in all the product informati on for the product catalogue, maybe the calculation is: * Duration = 20 days effort divided by 5 people = 4 days If we double the resources, we can get it done faster: * Duration = 20 days effort divided by 10 people = 2 days Suppose, instead, that we are scheduling a 4 day training course for the project team. If we decide to assign twice as many people it does not become a 2 day co urse - it is the effort figure that changes. * Effort = 4 days duration for 10 people = 40 days effort Very often, however, you know exactly how many resources you have - so that rema ins a constant. I only have 4 of this type of resource available, so if the job takes 20 days effort - it will last 5 days * Duration = 20 days effort divided by 4 people = 5 days In each calculation, we tend to lock one of the variables, input something that is variable, and thus re-calculate the third variable - otherwise a formula in t

he form D=E/P would have infinite solutions. Bear in mind that this simple arithmetic tends to ignore other complications. Co nsider whether it is valid in these cases: * What if we assigned 160 people to the task - could they have that catalogu e ready in 1 hour? * Assuming we have eight months before the catalogue is needed, would it mak e sense to assign the same task to one person for just one hour a day? * If the 20 days effort were spent on a "Conference Room Pilot", where peopl e discuss design options and try them out, would 10 people in the room instead o f 5 make it twice as quick or twice as slow - or even worse than twice as slow? Take a look at the discussion on "complexity" if you are not sure. This arithmetic and logic is more complicated where multiple resources are assig ned to multiple tasks, potentially at the same time (but that will depend on the detailed scheduling), in differing proportions. For example: Project Tracking * * * * Duration = 100 days Effort = 60 days comprising... Project Manager 10 days effort ==> resource level of 10% Project Administrator 50 days effort ==> resource level of 50%

So, the Project Manager needs to be available one tenth of the time on average a nd the Project Administrator needs to spend half time on this work. The duration of the work will be defined by whichever resource takes the longest to do their proportion. In this case, we would want to balance their effort and availabilit y figures so that they both work at the tracking task for the full duration of t he project. In other cases, it may be one specific resource that is holding up c ompletion. Bear in mind also the pitfalls you might discover, particularly with automated s cheduling, and the various tricks you might need to play to avoid them (as descr ibed earlier). What do you think would happen to this Project Tracking task if t he Project Manager had to work full time on a different task for a period of 10 days in the middle of the project? The effect of changing the resource effort - available as a PowerPoint97 slideTh ere are several complications in the "real world". In the estimating section, we examine the way complexity does not grow linearly with scope. Let's take a look at another complication and see how the complexity factor also affects that. The common view is that the more resource you make available the faster you can complete the project. It is important to understand that infinite resources do n ot lead to zero time. Adding in more resources helps you approach the fastest po ssible timescale - but there is a limit to how fast that could ever be. Applying Putman's Software Lifecycle Management theory" we see that a "limit of possibil ity" is approached - but never reached. We can also see that applying very high levels of resource or accepting very long timescales does not look like good val ue for money. The parameters you might adjust as a Project Manager would tend to be in the middle of the curve where putting in extra resource gives you a good return on investment. Barry Boehm in the "Constructive Cost Model" (COCOMO) allows for a series of cos t drivers that recognise the differing levels of complexity in the various aspec ts of the project. Allowing for the complexity factor we can see that you do ind eed approach the fastest possible time - but, once you reach it, putting in more resources will slow the project down.

A further thought on that from Brooks - adding manpower to a late software proje ct makes it later (1995). Forget the arithmetic you learnt at school: If one person can dig a hole in four hours, two people might dig it in two hours , but four people would fight to get their spades into the same space, and 100 p eople would probably never be able to get started. Dealing with complex dependencies Planning complex projects with many streams and cross-dependencies is never easy . The learning from the complexity factor discussion suggests that complex under takings should be broken down into separate less-complex elements wherever possi ble - provided you do not generate a new level of complexity in terms of the rel ationships between the sub-divided elements. Often the best approach is to identify separate streams of work autonomous layers of the overall business solution. Most of the l run along these streams. With good management, only a few key l cross over between the streams. You should identify these key points. This logic is particularly useful if you are managing a of sub-projects each with its own leader and sub-plan. which form semidependencies wil dependencies wil synchronisation project as a set with w need t as sep has to

Streams and Syncpoints - available as a PowerPoint slideA typical pattern orkstreams is to find there are points where many elements of the project o be handled in unison, and other times when the work can safely progress arate streams. Key milestones should be identified to show where the work come together and where it can split. Try to adopt a logical, structured approach to dependencies, for example:

* track input information or documentation back to where it was produced * link phases to phases * link activities to activities * link tasks to tasks * minimise dependencies between sub-plans; only use these where they are maj or sync points or major review points * likewise, minimise dependencies between streams of work or sub-teams * but - break any of these rules if you need to in order to state the correc t logic or significantly optimise the scheduling. Detailed planning work during the phase It is not good practice to keep changing the plan every time there is some diver gence from the original expectations (although it can be a useful way of hiding problems). From a practical point of view, it does make sense to recalculate the plan if there has been any significant change. The new plan would be based on t he current circumstances - to manage expectations and to schedule dates realisti cally. When you do need to issue updated schedules, you should retain the original vers ion of the plan as a baseline. This allows you to analyse progress and achieveme nts against the original targets. The planning work at phase end

Phase end is always a good time to review progress, check that objectives have b een met, tasks have been completed, deliverables have been delivered, quality ta rgets have been achieved etc. You should take a good look at the project's achie vements against your plan: * What can we learn? * What did we get right? * Why were there variances - bad planning, the impact of good or bad Project Management, good or bad team, or unforeseen circumstances? * If we re-use this plan - what should we change for next time? At this time or earlier you should also be preparing for the next phase of work. In particular, you will be developing the detailed plan for the follow stage of work. Wrapping up the planning work at the end of the project At the end of the project, its outcomes should be reviewed and analysed in much the same way as at the end of a phase. Here are a few specific points about the end of the project: This is when the project's accounting will be finalised, reviewed and reported. The success of the Project Manager will probably be measured partly in terms of actual performance against the plan. Planning and tracking information should be brought up to date and stored for fu ture reference. Past experience is the single most valuable guide for future planning and estima ting - do not lose that knowledge!