There could be a number of (sub) projects all kicking off at the same time as a result of this project definition in which case each (sub) project manager would need to plan the first stage of their (sub) project. (Sub in brackets because some people would call them sub-projects, others would call them projects and maybe call the overall thing a programme.) But as we said we are keeping it simple by assuming that only one project will start now - Release 1 of our new system, and that Stage 1 of Release 1 will comprise the Requirements Analysis and Users Functions Design steps. We must now plan this stage in detail and get resource commitments.
Planning this stage is like planning any other stage: working out what must be delivered (in our case a requirements document, a UFD document, a plan for stage 2, a revised business case and probably several other things too) and then planning who must do what work and when in order to deliver those things.
Note that one of the outputs from any stage is a plan for the stage that follows it (assuming there is one).
A key part of the planning of Stage 1 will be negotiating with the managers of the people we will need - users to define requirement, a business analyst or two, IT designers to be involved in the requirements workshops, the user and IT people who will do the User Functions Design and IT technical designers who will participate in that, a project office person perhaps, someone in the latter part of the UFD step to start thinking about testing, etc, etc, etc.
We may have those promises of bodies from steering committee members and other Directors but once again we are now talking to immediate line managers. Having obtained verbal agreement we formalise them in writing in a Stage Agreement for Stage 1. An outline plan will also be produced for Stage 2 (in our case Stage 2 will comprise IT Technical Design, Build and Test and User Acceptance). Stage Agreements and the mechanics of planning and scheduling will be covered in later chapters.
Everything is now in place, the project has been DEFINED. The project's business objectives are clear. An overall business
case indicates that a programme of many releases would be a good investment for the company.
The cost benefit case for Release 1, and thus the budget for Release 1, has been
approved by the Board of Directors. The project manager has defined and agreed all the roles such as
steering committee members, project user manager, etc, and the role players have agreed to perform those roles and their line managers have agreed to appraise them on how well they perform those project roles.
A PDW has been held and we have buy in from all the key players. Stage 1 has been planned in detail and resources
secured for it, the remainder of Release 1 has been planned in outline. We're ready to roll! But first we must
get formal permission to begin.
|
|
|
|
This meeting should be a formality. The project manager presents to the sponsor evidence that everything has been defined and planned, risks have been assessed, resource owning managers have committed the necessary bodies, etc. In other words we know what we're doing and we're ready to start doing it.
The very fact that the project manager must make this presentation to the sponsor should be a powerful incentive to get the project properly defined and planned. You would not go to that meeting saying the objectives are not very clear, the scope isn't clear, you're not sure what it's going to cost and you haven't really got any troops lined up to do it. Another swift exit from the Executive Suite. This meeting is like a Summit Signing Ceremony for an International Treaty. There is no discussion or negotiation at the meeting, it's just a formality, but the fact the meeting is in everyone's diary focuses minds wonderfully and work gets done to hammer out the details prior to the meeting.
In our case the project manager confirms Release 1 will cost about $1M (which the sponsor already knows having taken the business case to the Board of Directors), and the project manager says he is confident that Stage 1 will cost $300K or very close thereto.
The sponsor congratulates the project manager for managing the project definition so well and for getting
everything sorted out and the sponsor gives the project manager written authority to spend $300K on Stage 1. As we shall see,
at the end of Stage 1 the project manager will have another formal go no go meeting with the sponsor to persuade him
to part with the funds for Stage 2, which he currently thinks will cost about $700K.
In our example project definition took 10 weeks, involved 25 people and produced several outputs: project definition document (PDD), business case, Stage 1 plan and agreement and an outline plan for the remainder of the project. And if we break the plan into all its component parts we might end up with quite a long list (risk management plan, communications/reporting plan, quality plan, etc - see later chapters).
However, if your project is very small, project definition might take a couple of days of informal discussion and your PDD, business case, project plan and stage agreement could be combined into a single document that covers two sides of A4.
We must scale the controls to match the need of the project so that we don't smother small projects in a blizzard of documents they don't need.
By contrast, the project definition stage for a very large project, particularly if it is to be outsourced to a third party, will need far more paperwork than we have contemplated: formal legal contracts, health and safety documentation, many project plans for the many (sub) projects, etc. Furthermore, if you are managing a large outsourced project, you will find your Procurement Department, Legal Department and others will be very heavily involved, and there will, quite rightly, be strict standards you must adhere to and processes you must follow (tendering procedures, etc). But if you are new to project management we would hope it's very unlikely you'll be given such a project to manage as your first project!
There's practically infinite variability in the size and nature of projects and thus in the size and nature of project definition stages. Before you start you've clearly got to work out what's the most appropriate way of defining your project: a few days discussion, a formal project stage much as we described...? Either way, there should at the end of the project definition stage be a formal meeting with the project sponsor at which he, in writing, gives the project manager authorisation to spend company cash on the project.
Does doing project definition properly mean you have unlimited time to do project definition? No it does not. Project definition should be like any other piece of project work: planned and managed so that it is done quickly and properly. And if you do project definition properly the project itself will take less time, cost less, have happier users and be less stressful.
Good project definition is a very good investment.
In some organisations, particularly those hidebound by project management methodologies, some people - we hesitate to call them project managers - hide behind the bureaucracy and use it as an excuse for inaction, inertia and procrastination. "Sponsor, I can't do anything on that until you give me a project authorisation number." "Sponsor, I can't do any work on that until you give me a PDD." Rather say: "Yes boss, I'll get that done for you - I'll get a project number, work with you and others to get the project defined asap and a PDD produced then I'll get back to you with the costs and a project plan, etc and hopefully you'll decide to proceed."
In conclusion:
Good project definition makes project success much more likely.
"We haven't got time to work out where we're going, we're late already."
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book