So this post is a bit more work-related than most. I only recently covered household appliances and label makers so talking about managing IT projects is at the opposite end of the spectrum. But I have a bee in my bonnet and some of you who work in my industry might have some views on it too.There's the possibility here that this may be emotive enough to have some very dissenting views to mine!
I am a proponent of agile delivery: whatever flavour is best fit for the job at hand. But whilst delivering to priority, ensuring that benefits are being reaped as quickly as possible, and de-risking technical fog is all good, healthy stuff, I am aghast at how many projects I have come into or advised on that conflate the method of delivery with the practice of good project management. And of course the twisty knots that creates is often where I come in.
For a moment, let's go back to what project management is for: at it's core it's ensuring that a job gets done within the deadline, within the budget and to the standard required. It's the 'triple' constraint of time, cost, scope/quality. Project management is about identifying what bad things might happen (risk), dealing with with bad things that have happened (issues), understanding the relationships between things (dependencies) and using formal methods to ensure that all parties are on the same page about the current state of the triple (change).
User stories are great at describing function and well crafted-stories will be sufficiently explicit in the definition of done to detail non-functional requirements, such as the speed with which a task gets done or the quality of graphics, alongside what buttons will do, what the screen will render and what records will be updated. But it's not so great at the environmental context. A product backlog is not the ideal place to log "if the proposed legislation goes through then we will need to completely refactor the application we're building". Nor is it the place to monitor the actions against "oh dear we had a security breach" and all the face-saving communications, PR activities, and audits that go with that.
And whilst I am a very big fan of the social contract and transparency that come with the ceremonies, particularly daily stand-ups and retrospectives, they do not replace the need for appropriate team and account management. Stand-ups are there to gauge velocity and articulate impediments to progress, they're not a replacement for professional development nor performance management. The fortnight you fail a sprint because "instead of training you should just pick up a task outside your expertise this sprint and give it a go" is a fortnight you will regret. Nor is it pleasant to be arguing about what was yours and what was the vendor's responsibility because you didn't spend the time to define things clearly in the contract.
Before I start to get too much more on the rant, let me get to the point. It is good risk mitigation for the majority of projects, particularly in the application development arena, to consider and select agile as a delivery method. Waterfall is getting quite outdated and there have been too many projects that deliver products that no longer meet the need of today because requirements were gathered and technical design signed-off two years before. In some cases products don't even get delivered. But agile is not the panacea and no matter how strictly you may conform with your chosen methodology, it will not replace either the hard or soft skills of proper project management. You will still need typical documents and you will still need people who are motivated, know what they're doing and are good at what they do.
So if you don't want me or my equivalents being called in to help you fix it, be sure you pay proper attention to the wider context. And if I come in and ask for your risk and issues registers, your project charter and copies of your contracts, be sure they exist and are in good order.
0 comments:
Post a Comment