INTRODUCTION
In this simple guide to project management I will use the analogy of the Project Management Office being like Air Traffic Control for projects and change. The Project Management Office [PMO] will want confidence that any significant project or change is clear about passengers and crew (participants), fuel (budget), destination (outcome) and route (plans). For each initiative we want to be able to give it a thumbs-up or guidance on what is required for permission to take-off or indeed a safe journey: on-time, on-budget, to-specification, low-risk and high-communication.
This simple guide is based on a blend of Waterfall approach (plan before action eg PRINCE2) and Agile (work it out as you do eg SCRUM)
WATERFALL DECIDING WHAT IS NEEDED
Waterfall (plan everything up-front eg PRINCE 2) generally uses a Requirements Catalogue.
There should be a catalogue of requirements, categorised as Must-have, Should-have, Could-have, or Would-like (MoSCoW).
Requirement, Explanation/Criteria, Must-have
Requirement, Explanation/Criteria, Should-have
Requirement, Explanation/Criteria, Could-have
Requirement, Explanation/Criteria, Must-have
Requirement, Explanation/Criteria, Must-have
In the Waterfall we always ADD to the list, even changes are an ADDITION which is why time, cost, and risk always go up. We are committed to everything (including the things we now do not want!) and often only get the changes right at the end.
AGILE DECIDING WHAT IS NEEDED
Agile (make it up as you go eg SCRUM) generally uses User Stories which are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }
As a { type of user }, I want { some goal { so that { some reason }
User stories are often written on index cards or sticky notes and arranged on walls for planning and discussion. As such, they strongly shift the focus from writing about features to discussing them
In the Agile we always AMEND to the list so we only do the work for this period and wait to see what is in the list for the next period. It might be longer or shorter. We are only committed to the work in the current period (usually 2 weeks)
ROLES FOR DECISIONS AND COMMUNICATION
It is useful to think of all the people who need to be involved in communication, co-ordination and collaboration
Responsible: person who performs an activity or does the work.
Accountable: person who is ultimately accountable and has Yes/No/Veto.
Consulted: person that needs to feedback and contribute to the activity.
Informed: person that needs to know of the decision or action.
ATC MANAGING TASKS AND CHANGES
Changes to time, cost, quality, or output can be unwelcome because they impact the project being on-time, on-budget, to-expectation. This is particularly the case when change ADDS to time, cost, risk and problems. However change sometimes can REDUCE time, cost, risk and problems, and possibly improve quality.
WATERFALL AND AGILE APPROACHES TO CHANGE
Waterfall (plan everything up-front eg PRINCE 2) generally records any change to be EXTRA time, cost, risk and problems because we have agreed up-front all those elements and anything else (even a beneficial change) is regarded as EXTRA.
In these circumstances it is really important that there is a clear understanding of the change and the impact on time, cost, risk and problems and approval for the necessary change in budget, schedule or resources.
Agile (make it up as you go eg SCRUM) generally does not have a fixed idea on time, cost, risk and problems and so every change is just accommodated with the aim being to focus only what is needed and reject anything else. This focus means we ADD costs for what is needed, but REMOVE costs for anything else with the net effect that you only pay for what you need and agreed and nothing else.
CHANGE APPROVAL
In both cases it is important that the customer, end-user or owner is able to confirm what is needed and agree the change as well as the implications.
ABOUT THE BLOG
This is a series of coaching blogs that eventually will become a book. By blogging each item I hope to share each element in easy to read bite size chunks, maybe invite some people to subscribe to see the next posting and hopefully encourage some comments, feedback and suggestions which will improve the content for the blog and eventually the book. All comments and feedback are therefore welcome.
