Working on projects for a long time, longer than I care to remember, the same topic just keeps rearing its head.
Be it in the public or private sector working on IT or Business Transformation the same question comes up time and time again.
What am I referring to? Well in a nutshell, how are we to run our projects?
For those of us who go through the 5-year (or soon to be 3-year!) cycle of PRINCE2 re-certification we’ll be reminded of (what we know anyway) you must tailor your project to fit with the company/organisation you’re delivering for.
But it’s not really that simple, or is it? I think as an industry, change practitioners are guilty of falling in the trap of slavishly following a given PMO framework at the given employer. This gives a PMO a consistent metric to track against but for change delivery following this doesn’t fairly reflect the breadth or depth of change coming through in this information age.
Some projects/programmes are heavily regulated to a point where a good old PM becomes more a process manager than a PM. Others, typically newer PMO’s, are more of a free for all where people come in and help out with a sense of priorities but work first on who shouts loudest.
All this theory aside on how projects/programmes come into being, the core reasons for doing a project still should stack up:
1) Is the scope known? Can a sponsor say to you, as a PM, what they want from your project?
2) Do we have a business case (or at least a mandate) which demonstrates benefits which everyone can agree to? Does it tick all, or at least some, of the key measures (Specific, Measurable, Achievable, Realistic, Timely)? We all remember the courses and presentations taking about being SMART but it’s as valuable today as it ever was.
3) Is there a team in place to deliver it? Sounds obvious but often projects are initiated without a team agreed which creates a stack of work which doesn’t get beyond initiation and analysis paralysis.
But the $64k (or sometimes multi-million dollar) question is how, as change practitioners, do we go about delivering our projects?
Well, there is no one answer, and I think that’s the point really. What we can do though is don’t box ourselves in.
We can though have a great approach, think Hybrid:
1) What is the appetite in your company/organisation for Waterfall vs Agile can you mix it up? Apart from building rocket ships or doing 100% software product development, you’ll struggle to work in your career on out and out Waterfall or Agile projects. Therefore, it’s perfectively reasonable to propose to do a bit of both when it suits.
2) If you find yourself having to explain or justify to a sponsor why you’re using Waterfall or Agile you’re (in my humble view) doing it wrong. I’m terrible at plumbing, much to my wife’s chagrin, so when my local plumber comes along to fix my loo, I don’t ask them what method they’ll be deploying to fix the flusher (is it even called a flusher?!) I just want to know how long, how much and they will not leave a mess. Why should a project be any different?
3) Focus more on a product and less on a project. As a PM I consider the project to be my baby to nourish and grow and own, it’s a living thing which I need to look after, beyond me though in the business world it’s delivering something that has a product at the end. If it doesn’t why are we doing it? Again, the how we do it part is less something to get hung up on and having to explain, to reference the previous point.
4) Delivering the product is the single most important factor, we could have what is considered a brilliant change methodology but if it doesn’t deliver, no-one is going to thank you for having a wonderful PMO process which ticks all the governance boxes if you can’t get product out there.
In summary, what I’m saying here is be more focused on what your sponsor wants and worry about explaining the method later.
Within a high performing team, I’ve worked with we had a motto GSD - Get Stuff (or replace with something more choice!) Done, rely on your experience and judgement to make the right calls to deliver our projects.
by Andrew Gallagher
source
No comments:
Post a Comment