The paradox of small projects

In Project management on October 30, 2008 at 9:29 pm

Late last year I was asked to help deliver a ‘small’ project. My workload was fairly loaded so before I agreed, I checked the scope had a quick discussion with the selected implementation partner to assess what was required. It seemed like a quick and easy project, so I agreed to be the project manager. 12 months later, is this really a small project?

On reflection, here is what went wrong.

  • I perceived the project to be small based on limited information / analysis
  • With the project only expected to last three to four months, I trimmed down my project management activities like abbreviating the stakeholder analysis process, gaining organisational change management input, and benefits management process
  • I viewed my involvement as part-time
  • Last and potentially the worst, I assumed that the organisation understood and wanted the project (I based this assumption on the fact that a team of people across each department had come up with the project concept, a team member had prepared a business case, and the Senior Management Team had approved the business case).

How did these ‘wrongs’ manifest themselves during the project:

  • While we defined the potential business value, we did not have a clear or detailed plan of how we would realise this benefit.
  • The project team showed signs of stress as project work chewed up operational time, and additional but necessary tasks were treated with dread.
  • The team that would own the project deliverables at project completion continually challenged the value of the project.

What would I do next time?

  • Spend more time on understanding, documenting, and agreeing benefits and the process for their realisation.
  • Complete a full stakeholder analysis supported but a full communications plan and change management plan.
  • Plan with the end in mind; for example, define and agree who will be the operational owners of the project deliverables and ensure that they understand the value for the organisation and to them personally.

I am interested in your thoughts on managing small projects particularly when you have other larger project on the go at the same time.


Operational cost approval in business cases

In Project management on October 30, 2008 at 9:27 pm

Hindsight is easy. I have been writing business cases for years and have just realised a fatal error. What happens where the person responsible for an ongoing operational cost for a project deliverable is not part of the business case process?

In most cases this doesn’t happen but I have just completed a project where our procurement and finance departments initiated a project, where one of the ongoing operational costs is an information systems cost. Long story short, the information systems team do not want to pay these ongiong costs as they have not budgeted for them.

I hope there aren’t too many others in this position, as it’s an embarassing one!

I have now updated our business case template to add a budget owner column for the ongoing operational costs, and added operational cost owners to the approval page.

Three strikes and you’re out

In Project management on September 25, 2008 at 8:46 pm

Have you ever been working on a project and there is a recurring issue with a deliverable. You discuss the issue with the people involved – nothing happens, you discuss the issue with the project sponsor – nothing happens, you discuss the issue with the steering group – nothing happens. Well guess what, you probably do not need that deliverable. If the deliverable were important, it would have been completed a long time ago.

Something I heard a long time ago, was that if something is delayed twice drop it. I would expand this to give the project sponsor one final change to justify the deliverable. That is, the sponsor must present a compelling case why the deliverable is still required and then provide significant reassurance that he will support the completion of the deliverable. This expands the two strike rule to a three strikes and you’re out.

Follow the three strikes and you are out rule to stop wasting time in your projects riding dead horses, and to ensure that you are focused on the priority deliverables.