How not to do project management

somuchfailBack  in 2012 I wrote a blog post about the ‘new parent‘ method of project management.  Now, I cringe when I read that article, because I was missing some fundamental principles behind the project management methodology.   The proof of the pudding was definitely in the eating, as I ‘tested the theory’ in a deployment of a product called Druva InSync across our estate.  Unsurprisingly, it was not as successful as I’d hoped, but the reasons why are useful lessons to learn.

So where did I go wrong?

In summary, I’d said if you were in a small IT department with no ring fenced resource, you could still deliver projects successfully if you had everything you needed to hand, were agile, persistent, and pragmatic.  This, I should make clear (with hindsight) is missing some fundamentally critical elements of a project plan, without which you are highly likely to fail.

The approach I’d taken was as follows;

  1. Define the problem (we did not have a reliable data backup option for our laptop users)
  2. Define the solution (install a laptop backup project, Druva InSync)
  3. Write a business case to justify the costs including staff time

All of this was defined in a Project Terms of Reference, along with a very brief description of the scope, project team, the business case and the constraints.

One particular problem with this approach was my half arsed baked attempt at requirements gathering, which meant we didn’t understand the use cases our the product would have to satisfy, and as it turned out there were a number of flaws in the product which hindered the implementation or reduced the quality of the solution.

However, the lesson I learned here wasn’t specifically about requirements gathering (though this is a key part of any solution design), the most important thing I took away from this project, was about assumptions.

assumption: a thing that is accepted as true or as certain to happen, without proof.

Assumptions MUST be documented

In my case, I’d made a number of assumptions;

  1. That I understood the use case completely
  2. That the best options was an off the shelf product solution
  3. That Druva was the best product

It turned out my assumptions were all wrong.  So what should I have done?  Well, for a start I should have got a qualified project manager to either run the project, or at least advise me on the most important steps I could take to increase the chances of success.  But more specifically, I could have managed those assumptions as part of the project.  If you make assumptions in any project (and you almost certainly will, in fact you probably have to), then;

  1. make sure you know what they are,
  2. document them,
  3. if they are important enough, validate them
  4. decide whether constitute a project risk.

This wasn’t the only mistake I made in my approach to project management, there were countless others, and diligence was a common theme.  The one which I was most guilty of though, which had  the most impact on the outcome of the project, and which I learned the most from, was making assumptions.

As the Association for Project Management puts it, a project is measured by whether it “achieves the objectives according to their acceptance criteria, within an agreed timescale and budget”.  If you make assumptions about any of those (in my case the acceptance criteria and timescales) you can probably guarantee your project won’t deliver!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.