The concept of Application Lifecycle Management is not a new invention that just popped out last year and hit us in our backsides. It’s a very wide topic with a lot of categories, which includes categories such as:
- Project Management
- Change Management
- Release Management
- Design, Modelling and Issue Management
Yes, that’s right guys and girls (honestly!!) – Project Management is indeed part of the Application Lifecycle (for real this time!!).
This is spread over an even larger list of methodologies and tools, some fluid/agile and some integrated…
We often hear that IT projects are more likely to run over budget, be delivered late and in a state of looking like a bug-ridden open source project…. statistically that’s quite often the case – so why do we bother when we’re doomed for failure? Well, because when things are done right, it just works.
One of the biggest mistakes I frequently notice on IT projects is the failure to understand that it’s not just the development and project management team which has to adhere to a process. (Yes, i know, those that pay the bills just want things done now…you arguing?…s’ok, there’s the door). IT projects are like a house of cards, the more you add and the more complex the “build” becomes, the more careful you have to be – so that means following that process even if it means you have to get approval before proceeding.
I was once assigned to a project to resolve a few bugs here and there. Nothing major, this was final stage of the project, just a few helpful hours when the cycles where free. The first issue I was assigned wasn’t that complex, but getting to grips with the code base and project layout did take a bit of time. It wasn’t really documented and there was nobody around to give a hand. Anyways, after about 1 1/2 of trying to reproduce the alledged bug, I finally gave up and tracked down the BA who’d lodged the bug to start with. For the first 30secs the BA had to get their head around which particular bug I was referring to – all understandable, the project had run for years.
Then it dawned on the BA which issue i was referring to…the message was…
That issue was fixed 1-2 days before it was assigned to you…
Ok, naturally I wasn’t entirely impressed, so I chased down the PM that’d assigned the issue to me and got the usual blabber about “being newly assigned onto the project” and “we’re all in this together, please stop strangling 
me…garggle..ugghh..gasp”.
So the incident at least had a release for my homicidal side..
Why did the Project Manager assign the issue to me in the first place? Well, he’d been running around, trying to get resources stitched together to complete the project and get it out of his hair. Yes, he was a newly assigned PM and the developers on board were largely juniors. Obviously a failure to communicate on one level or another….or….something a bit more sinister?
The steps pretty much showed a full breakdown of the lifecycle.
Test conducted -> Issue Found -> Issue Raised -> Issue Triaged -> Issue Fixed….
And then that’s where things really broke down. No detail was found in TFS that the issue had been fixed. It was still assigned to the PM. Still in active status.
Obviously the PM was never informed that the issue had been fixed..who’s to blame for that? The developer? the tester? the PM?
It’s a very basic example of what can go wrong when the process isn’t followed by everybody involved. That includes developers, testers, project managers, stakeholders etc.
Considering how simple this was, the cost was huge and the ROI so small as to be negligent. Look at that from a project perspective, a drop in the ocean, however if that happened often enough the project would fail (unless we had some seriously generous clients and budgets).
Look at this from an enterprise perspective where cost of delays, additional licensing and hardware, consulting resources et al, then it’s obvious that the lifecycle is paramount. Had a process been in place above (well it was, but it obviously wasn’t followed) the waste of time (and additional cost to the project) could have been avoided.
Shortly after that incident I received an email, asking me to make a small change (just a date calculation, v.simple and quick fix) to another feature. I naturally understood that the work item had been assigned to me so I could see all the details of the change (and ensure nothing had been missed in the email), but alas, it hadn’t. Due to timezone differences I needed to wait for the PM to get back on board for the day, to ensure that the details I’d been given in the email was all encompassing. The work item change had been raised as an issue to be resolved – and lo and behold – it also hadn’t been assigned to me. Great, now due to check-in policies in TFS, I wouldn’t be able to check in before the change to go to the test team. Again, and added piece of delay that ends up costing money in the long run. Of course, I could go and make the change to the code base, wait for the issue to be assigned to me, check in and then move on. But, here’s another idea.
How about I DON’T do the work before the “paperwork” is all sorted?
Yes, I waited patiently for the PM to respond to my email – “S’cuse me, sir..please assign issue xx to me and verify all details…kthxbai” – and then I proceeded.
Did it take a bit of extra time to get this done? Of course it did, but what could the consequences have been had I not gone down that path? Again, wasted time and even possibly impacting code and changing features which wasn’t meant to be changed. Again, more wasted money/time/resources.
This is just a small example of why being very careful to follow a set lifecycle is paramount to IT projects – in the whole scheme of things, this wasn’t something major really – however, the project had already rolled way over budget and deadline, why continue to waste resources when a simple process could have prevented it all.