For those of you who have managed or sponsored a software development project, we salute you! For those of you in the South, bless your hearts. You’ve been in the middle of the trenches and been witness to the ups and downs of project dynamics and lived to tell about it, with or without the t-shirt. You are the warrior!
The only thing to be sure of is uncertainty – wisdom from a goat
Even the best-laid plans are subject to the whims of a bulldozer and circumstance. A perfect example being when a meticulously thought out project experiences a change that blows the plan apart. But what could some of those changes be? I’m so glad you asked.
Stakeholder changes their mind
If you think that could never happen, you must be new, because yeah, a stakeholder has the right to change their mind at any point of the project. It doesn’t matter if it has to do with a great idea or an enterprise-wide change in strategy, you own it. Nothing puts a wrench in your entire plan more than your stakeholder throwing a new idea or twist into your requirements and forcing you to have to start over again, beginning with those requirements. On a good note, at least your project is still alive, so we smile, say, “I can make those changes,” and call an emergency meeting with the team.
Catch these changes early, and the best-case scenario is a little reshuffle of resources. If the request comes mid-project, the rework is going to make you want to feed your Gantt chart to a goat.
Regulation changes
You thought you had your requirements, and they were bulletproof this time. They were until a new regulation was announced, and your output must be compliant with the latest changes. This change is nothing you can argue or negotiate out of, but your team will make it happen. Back to the smiles, and the drawing board…
New/more/different requirements shake out
I remember a DOE (Department of Energy) project that was 80% done rolling code to different functional teams in each sprint. Each feature was supposed to be the same with some minor details specific to each group, and it was smooth sailing until it got to the nuclear energy team. This pickle falls partly into regulation changes, but there were no changed regulations. Instead, it was a new business analyst that failed to inquire when gathering requirements for this group if there were regulations specific to nuclear operations. With this new discovery, we had to make a hard stop and go back to the drawing board. The hungry goat got a snack on this one too.
All to what consequence?
When any one of those examples occurs, it’s time to put on your tap shoes and start dancing. Yes, changes will happen, and there will be consequences to any change, but when it hits, it’s time to learn some new dance moves. Here’s what we typically see when things go south on a software project/program so you can identify the symptoms of a problem.
Code quality suffers
Changes mid-project present increased chances of defects and rework. Even code that worked perfectly can lose compatibility with the latest changes. If testing is not adjusted effectively, defects are at risk of finding their way to production.
The fortunate will catch those bugs during whatever testing there is currently. Those not so lucky will deploy the bugs unnoticed until they either cause an outage or the client finds them, but in both scenarios, the backlog of bugs and technical debt grows.
Meetings and more meetings
Significant changes mean more meetings. There will be status update meetings to yell “STOP” so you can regroup and press that reset button and let the team know what happens from here.
There will be new working sessions to gather all of the latest details and requirements before the project can proceed with reshuffled requirements and resources.
New coding requirements may conflict with code already in a release branch. Worse yet, changes may affect code in production, which comes with a new series of meetings with the service desk or problem management to gauge the depth of the problem and prioritize the necessary rework.
What follows all of these meetings? You guessed it – MORE meetings. Once the triage calls are complete with customer support, next come the changes, and they are all urgent. Emergency releases are needed to correct the affective code in production, leading to an increased number of emergency bridges to make it all possible.
*ALL OF THIS IS WASTED TIME AND MONEY*
Missed deadlines
Despite the astounding response to the many moving targets to a project, deadlines often (attempt to) remain static despite the plot twists. Additionally, because the slower time to market leads to decreased profits for the company we dance like there’s no tomorrow. It’s all part of the fun. After all, time is money!
Bring in your guiding light
Whenever significant changes occur to code mid-way through a project, meticulous attention must be made when testing to analyze the effectiveness of the marriage between new and old code. These extra steps along with what you’ve incurred along the way will add extra time past your original milestone dates.
Here especially, you’re in need of a higher level of QA support for these new and unique demands, but it’s also an excellent time to reshuffle your testing strategy with the A-Team of QA testers at Lighthouse.
So when you’re faced with a time crunch, our True North Methodology can help keep the project moving as fast as your developers can recode and with a rock-solid timeline. We can also offer suggestions to make up some of that lost time by introducing and implementing improved testing tools and methods.
That said, time is of the essence, and we can do our best work from the very beginning, so don’t hesitate to call us when your hair is on fire after a big bomb was dropped on the project. We at Lighthouse Technologies have seen it all. Contact us and let\’s calm those fires.
