Over the years I’ve been involved in countless IT projects. Lots of them have been software development projects, but I’ve also done other types of IT-related work. I’ve been a team member (working for a project manager); I’ve been the project manager; and I’ve also managed a programme of multiple projects. Not all of them have gone smoothly by any stretch of the imagination, but here’s eight tips from my accumulated experience…
1. Keep in mind the project triangle
If you always keep in mind the project triangle, it will frame lots of your decisions and communications. It basically says that there is a tension between three elements. Two of those elements are time and cost, the third element varies - but for projects I’ve worked on you could consider it to be either the specification or the level of risk on the project. The basic tenet of the project triangle is that you can optimise two, but not three, of the elements. So, for example, if you want to build a piece of software with a fixed specification (spec element optimised) in half the time (time element optimised), it will cost more money (money element is made worse).
Generally, many day-to-day decisions, big decisions, or externally-driven changes to the project can be couched in these terms – if you understand that you can’t have all three things at once, or that changing one element has a knock-on effect on the others, you’ll be much better at predicting the direction of your project. See our previous article for more details on the project triangle.
2. Get stakeholder engagement
Pretty obvious this one, but getting your stakeholders’ / project sponsor’s buy-in to what you’re doing is crucial. Doing this near the beginning is very useful. Normally after you’ve had the briefing of what they want and you’ve had a chance to put together your plan is a good time to present your plan back to the stakeholders. It gives you a solid foundation on which to execute because your stakeholders are on board and have had the chance to critique your plan.
Keeping them up-to-date regularly will also be appreciated. If the project starts veering off from the plan then keeping them in the loop is a good idea and it shows you’re aware and are doing something about it. Saying ‘we may have a problem’ or ‘we have a small problem’ is much easier than trying to fight it on your own (or worse ignoring it) and then surprising your stakeholders with ‘we have a big problem’. You never know, your stakeholders may have ideas about how to get it back on track!
3. Come up with a concise definition of the purpose
This is so that you can answer questions such as ‘what’s this project about?’, or ‘what are we trying to achieve?’. You’ll have to answer this question numerous times so it’s worth having an idea of the key message. You never know when you’ll be asked to do your elevator pitch to someone important – if you can do it quickly and concisely it shows you know the key mission of the project hasn’t been lost in the detail of execution.
Decide, near the beginning of the project, what’s in scope. Just as important is to document what’s out of scope – what could someone reasonably, but erroneously, assume was in scope? Or, what are you going to deliver? What are you not going to touch?
As the project goes on, the scope could change. It’s always a good idea to document the scope change – so that when someone asks why the budget has doubled, you can respond by listing the scope increases.
You can go very sophisticated with your plan, but beware that the more detailed it is, the more effort will be required to keep it up to date.
Just a simple list of tasks in a spreadsheet is a good starting point – you can then add estimates for each task and assign resources to them.
If some tasks depend on the completion of other tasks, then consider using a Gantt chart. It usually reveals something surprising about the order in which you should tackle tasks; very often completing a small but crucial task can mean that lots of other activities can start.
6. Have some contingency
Contingency is the recognition that the reality of the project probably won’t meet the idealised plan, and that it’s very possible that reality will be worse than the plan. The project could take longer, cost more, or not achieve its original scope. All of these aspects should be considered at the outset and you should build in time, cost and scope contingency to your plans.
You might want to add in a percentage for cost overruns. It’s rare that everything goes so well that all aspects undershoot their cost estimates. 10% should be the minimum figure but if there are lots of unknowns a higher amount may be more suitable.
For time contingency, it’s worth adding in extra periods for a number of things: originally planned tasks that take longer; new, unplanned tasks; and breaks where resources aren’t available. Adding these in mean you’ll probably get a more realistic finish date.
As the project progresses, ideally you’d track how much contingency you’ve used. If you’re 25% through your project but have used up 75% of your contingency, you may have to re-plan.
7. Stay on top of the plan
Review the plan regularly and make sure it’s realistic, even if you don’t like what it’s telling you. Don’t be afraid to re-plan if something big happens (but keep copies of the old plan). Make sure people know what the immediate part of the plan is, what the next milestone is – this will focus everyone on making real progress.
8. Communicate in writing
Do boring stuff like confirm, in writing, key decisions – you’ll be amazed how often this can save your bacon and head off misunderstandings before they can take hold.
Take meeting minutes. It’s old-fashioned but very useful to record key decisions and also to assign actions and track them to completion.
Let people know when milestones are hit – if you do this by email you’ll have a record of exactly when these events happen.
Neil Tubman, Terzo Digital, February 2017