These were the words just a couple of days ago in a Facebook chat with someone I met in the twilight of my career. She wanted to catch up with me to talk about project management – a nice thought, but what have I got to say?
I got to thinking. I spent most of my career doing project management or something very close to it. Even in the last few years when I was supposedly into business development and marketing, a lot of my work was informed by project management experience. It’s a lot easier to sell a project development if you can talk intelligently to the customer about what’s involved. Trouble is, like many areas of expertise, if you know what you’re doing project management seems obvious – until you see how badly some people do it. In this blog I’m simply going to skate over the surface, stating the obvious – I don’t think anyone would want to stick around for the full treatment, and I’m certainly not going to get into a philosophical discussion about waterfall or agile methodologies.
Project delivery happens in phases – some of these can overlap, sometimes they become iterative, but delivery of a project is about moving from nothing but an idea to a set of tangible deliverables. Often when projects go wrong it’s because people forget about some of the phases, and even more commonly they work with a silo mentality, limiting communication across departments and disciplines, which can lead to less than ideal project outcomes.
Someone has an idea which might become a project. But what is it? In this phase we are talking about the “what” and the “why” and emphatically not the “how”. Techies will want to discuss the “how” at the earliest opportunity, and often either forget about the “what” and the “why”, or think they know better than the customer/user/stakeholder. This phase is about defining the requirements. To do it properly we need to work closely with the customer, users and stakeholders, as well as the breadth of company activities such as sales, marketing, finance, customer support and training.
- Deliverables – agreement of all parties on the deliverables is crucial. If we don’t know what we’re delivering, how do we know when we’re finished?
What is actually wanted?
What will it do and why?
What are the benefits?
Can we identify customers, users and stakeholders and do they agree on the objectives?
- Budget – in most environments a project must make financial sense.
What budget do we have for delivering the project?
How much is it worth spending?
- Timescales – a project is usually only valid in a particular timeframe.
When is it needed?
When would it be too late?
Is it possible to be too early?
Once we have a handle on the requirements, we can start thinking about “how” we will deliver. Typically we will discover things in this phase that cause us to go back and consider the requirements. It’s fine to go back and revisit the previous phase, but make sure you don’t get confused between the “what” and the “how”. We still need to be working across the many departments of the organisations involved – very often the technical teams will think that they own this phase. They should not!
- Resourcing – we need to determine who will be involved in delivering the project, and where will the money come from.
Who is in the project team?
Do we need external resources?
- Cost – this is deeply dependent on all of the other parameters in this phase. It’s pretty important that the development cost is in line with the budget identified in the previous phase. I have worked on many projects which would not have happened if we’d known the true costs when we’d started. There can be ways around this, such as finding other revenue streams based on the development (maybe technology licensing, for instance).
What will it really cost?
Who pays if we’ve got it wrong?
- Technology – we need to consider the technology we will use for this project, both in terms of the underlying deliverable and the tools used to develop it.
What technologies could we use as the basis of the project deliverables?
What about development tools?
Do we have experience is these technologies?
Do we need external resources?
- Timescales – this is a different question from that in the previous phase. Then it was “when do we need it?”. Now we’re asking “when can you have it?”
How long will it take to create the deliverables? Even if we could estimate perfectly (and we can’t) there is no single answer to this question. The deliverables might come in parts over a period of time, or be delivered in a number of different ways. It might be possible to deliver earlier if we were to spend more money.
How long will it really take? Think about risk. You need to be realistic about the timescales and factor in some contingency. If the project is very similar to 10 you have repeatably done before then the contingency can be small. If it’s based on brand-new technology that no-one has ever used, it will probably take twice as long as you think, even when you have factored in some contingency.
- Methodology – in the good old days we (in theory) carefully defined a project specification in minute detail before we started the development process. It is fashionable nowadays to use agile development, which takes account of the fact that we don’t know everything we need to know before we start. Each methodology has its advantages – and its disadvantages.
On a technical project, this is what the developers regard as the real work. They start coding and developing the electronics. But in the real world we also need to take into account the needs of the marketing department, sales, customer support, and test teams. Many immature companies regard these as serial activities rather than taking a holistic team approach.
- Progress tracking – the methodology zealots will talk of stand-up daily meetings for agile developments, or meticulous tracking of hours spent and earned value for more traditionally run projects. This is what some people regard as the core of project management.
Are timescales on track? It’s an easy question to ask, but devilishly difficult to answer. It’s often the case that projects stay on track until the 80% point, and then take as long to finish as they took to get to that point.
Are costs on track? This one is probably even more difficult to answer
- Customer management – also taking account of users and stakeholders.
Is progress what we expected? We need to be setting appropriate expectations.
Have we met unforeseen technical obstacles where the customer could help? Sometimes we can struggle expensively to solve a technical problem, when talking to the customer would have established that it’s not important.
Are there potential follow-on projects? We might have decided to postpone solving a problem until later, or have identified an opportunity for further development. We need to start talking as soon as possible.
- Scope – almost certainly the customer will realise at some stage that the original requirements were not correct. That’s fine, but we need to realise that the later we make that discovery the more it will cost. Moving goalposts cost a lot of money – but there’s no point in delivering something which is no longer appropriate.
Is this a real requirement, or just a nice-to-have?
Is the whole of the customer organisation in agreement?
Has the customer analysed the benefits?
Have we analysed the full cost and timescale impact?
We’ve finished the project, so we hand it over to the customer and (if it’s that sort of project) get paid. Simple! Ideally handover is an event, not a phase. But in reality, not everyone agrees that it’s finished, and it’s probably not on time. If we’ve been doing it right the other departments will have been marching with us during execution, now they come to the fore. Sales, marketing, training and customer support all need in their own way to get hold of the deliverables and work their magic.
Do we have agreed actions, timescales and payment schedules to tie up the loose ends?
Can we make sure the developers don’t disappear to more exciting projects before they’ve finished the job?
Have we scheduled a cross-functional project review (including the customer where appropriate) to analyse and learn from this project?
Have we kicked off the process to secure follow-on work before we lose the team expertise?
Have we put in place appropriate warranty and support processes, taking into account the probable change of timescales since they were initially agreed?
Post delivery support phase
This is both an opportunity and a problem. The customer, users and stakeholders will probably want the deliverables to function for many years. But the project development team will be working on new and exciting projects. An existing (and happy) customer is a valuable asset for up-selling and cross-selling.
Are we staying in touch with the customer to ensure they’re happy?
Are we looking at opportunities to upgrade the original deliverable, or move it on in relation to today’s technology?
Do we have a succession plan to ensure that developers have an interesting and challenging career path, but we maintain the ability to support legacy products?
No-one agrees how many phases there are, or what activities take place, but here’s another view: