As this is my inaugural blog entry, I thought I would start with what you need for a project start. Actually, what you need to know before your projects start. Projects are not free. Never have been, never will be. So before you start a project, make sure you know these three vital things. If you choose to skip or skimp on your knowledge of these three things, you will (guaranteed) do the wrong things, involve the wrong people, do re-work, do duplicate work, Â do inappropriate work, and did I mention doing re-work. On top of that, you will not finish on time or anywhere near your budget or deliver anything recognisable to the client/customer/userâ¦ so please, just know these three things before you start!
1 Know the end
As Stephen Covey famously said, âstart with the end in mindâ. You should really understand what the end of your project will look like. Explain it in the most understandable, recognisable, straightforward language you can. Because not only do you need to understand the end, but so does everyone else.
Once you fully understand the end, you can then put plans in place to get you there. Itâs the same idea about going on holiday. Unless you know the destination, you canât book the right travel arrangements, book the right hotel or pack the right clothes. How you describe, capture or document the end is up to you and the needs of your project. Some organisations have formal templates for formal documentation, some have nothing and you are required to create it. Some of the common ways to capture the end include one or a combination of the following:
- An inspiring statement about a better future after the project is complete and the wonderful differences that are in place. Itâs written as if the change has already happened and it implies how great it will be then. Itâs also short and memorable so you can share it easily with stakeholders.
- These describe exactly what you are trying to achieve with your project. They are usually in the SMART format (Specific, Measurable, Achievable, Realistic and Time-bound). Along with Targets, they will be what you are judged against at the end of your project, if you were successful or not.
- Also known as constraints, these are what will represent your goals to shoot for throughout the project in terms of Time, Cost and Quality. These need to be defined, agreed and understood before you start, so you can make sure you deliver on time, to cost and to quality and the customer will be happy!
- The Scope list describes all the outputs and activities the project team will be responsible for creating and doing during the project. This list also records things that are âout of scopeâ for the project â things related to the project, but are not the responsibility of the team. If this is not defined upfront, the temptation will be to add and add and add to the project without the additional time and money to accompany these add-ons. So at the end, of course the project will fail – the scope doubled because it was never fully understood in the first place, but the original targets of time and cost were never adjusted to compensate.
- Outcomes (how will this change the organisation?)
- These describe how the organisation or customer will be different because they will have access to and use the outputs that the project delivers. For example, the users are currently capturing all transactions with pen and paper. After the project, they will have access to and use the new IT system. The business will be faster and more efficient.
- Why is this needed? message
- If the change is not needed, then it should not be started. So an explanation of why the change is required will help stakeholders understand the reasoning behind all this effort. The business spending all the money will really need to get this, and if they donât or donât buy into the reasoning, again, it should not be started. It will only fail.
- WIIFM message (âWhatâs in it for meâ message)
- The WIIFM is the âwhatâs in it for meâ message. Not only does the business need to know why they are getting involved in a project, but the users and everyone affected by the project needs to understand the WIIFM. If people donât understand why they, individually, need to change, they wonât get behind it, either.
2 Know the start
Now that you know the end, you need to know the start. If you donât fully understand your starting point, you will make erroneous assumptions and decisions that can adversely affect your project. You might believe you already have an accurate accounting system, so you build an automated process to capture data, transfer it into a reporting system and publish reports to a wide community of stakeholders. Unfortunately for you, your Accounting Department know that the current system as it is today, is quite dodgy and temperamental and old. They normally have to check, double check and adjust the numbers to make them âaccurateâ before starting any reporting process. Oops.
By capturing the starting point accurately, you can start to see the amount of work and effort truly needed to get to that end state described above. You might be lucky and this will be a quick, short blast to get from where you are today to that desired future state. Or you may realise that youâve got years ahead of you before you start to see anything that resembles the end. But at least, now you know for sure!
Some of the common ways to capture the start include one or a combination of the following:
- Current state assessment
- An accurate description of your current processes, technology and staffing levels and skill sets. Your starting points with these will indicate how much effort is required to change into your desired end state.
- Baseline measures
- If the customer is looking to get faster, more efficient and more profitable as a result of this project, it is important to capture the current measures of speed, efficiency and profitability. Otherwise it will be impossible to tell if you are achieving any of these things. It will all be hearsay. What right minded person will pay for a project (with either with money or blood, sweat and tears) for âhearsayâ in return? Hopefully, no one!
- Stakeholder Perception
- This is a description of how stakeholders currently view this change. Is their outlook positive or negative? The amount of work required to gain their buy in might be quite time consuming depending on their starting point.
- Why canât we stay the same? message
- This message to stakeholders provides the evidence and explanation of why the organisation has to change. It might be drastic and bold like âweâll go out of businessâ or âweâll lose market shareâ, which are jolting and mind-focusing (if they are true, of course). Even if itâs not a life or death reason, a reason is still required to spur and garner movement and support for the project.
3 Know the gap
Now that you know the end (B) and the start (A), now itâs time to fill in the gap between A and B. You can start putting together all the plans, identifying all the work to do, appointing people with the right skills to do the work, organising the work so that it fits within the constraints of time, cost and quality whilst still meeting the Objectives.
The important part of planning is not the plan. The important part of planning is the act of planning itself â fully understanding the work involved, the order you want to do it in, the dependencies between different pieces of work, etc. If you know that kind of information, you can respond intelligently to problems and changes. If youâre âflying blindâ, without the big picture understanding of how things âshouldâ go, you will overreact to small problems and underreact to big ones, because you donât really get it, you never really planned it out.
Some of the common ways to capture the gapÂ include one or a combination of the following:
- A plan is a schedule and a documented explanation of the schedule. It includes the flow of work to be done in what order, recognising when some things can happen at the same time and when things have to happen one after the other. For example, with a construction project, a foundation needs to be built before the walls can go up and walls must be in place before adding a roof. The schedule is only half the story though. The documented explanation adds context around the schedule to remind you (and others) about dependencies, decision points, risk mitigating activities, assumptions made, etc. These will be forgotten unless documented. And if theyâre forgotten, I can only guarantee you one thing, they will come back to haunt you!
- Risk Register and Issues Register
- Although you hope risks and issues donât happen, you know they will. So being prepared for them whilst youâre filling in the gap will be imperative. Having registers to capture and manage them will help you stay in control in that journey from A to B.
- Project Team Role Descriptions
- Team role descriptions are important to understand who is doing what. Thereâs nothing worse than two people doing the same thing not knowing the other is working on a piece of work, except for when two people donât do something, each thinking the other is responsible. Clear roles help eliminate this confusion, which might escalate to conflict if not addressed.
- Project Charter / Project Initiation Document / Terms of Reference
- The plan shows how the project will run against time, the role descriptions explain who will do the work, but more information is needed to manage all these people doing all this work, especially with really large or complex projects. The Project Charter explains the management and governance of the project â how reporting will be done, how stakeholder communications will be handled, how problems will be escalated, how documents and outputs will be filed and stored (and who will have access to what).All of these âhowâ decisions will make it a lot easier for the Project Manager to manage the project. He or she will not have to think these things up on the fly, the decisions on how to manage the project will be made before the project starts. It will just be a matter of following the agreed rules. Of course, if the rules donât work, they should be reviewed for changing, and if agreed with the Project Sponsor, changed.
- Business Case
- This usually is the official document that justifies spending all this time, money and effort on the project. The business that is paying for this project needs to be psychologically and managerially committed to doing the project. They need to understand and agree to pay for all this work only if they truly believe that the business will be better off at the end. If the case to the business is weak or vague, the business will probably be better off staying the way they are in the current state, or spending their time and money on a different project that will give them the improvements that they are after.
Once you know these three things, go for it! You will actually enjoy managing your next project. You will be prepared to deal with problems (and occasionally really good surprises you werenât anticipating) because you know your starting point, your ending point and the journey to get there. Donât get me wrong, it will not be smooth sailing, even on a straight forward project. Thatâs life (sorry if I just spoiled some illusions). However, with this knowledge you will have a much easier time than you would have had without it. Thatâs for sure.
For more information on how to know these things, Terrapin Agrada is offering a self-paced, online training course â AMAZING Project Management.