If you’ve worked in software development and/or quality management (QM) for many years, you’ve probably found yourself in all kinds of thorny situations when it comes to managing the software development lifecycle. In my twenty-six years in this profession, I sure have, and I have the bruises to prove it. Missed deadlines, buggy releases, upset customers, and cranky bosses drilling me on why I didn’t foresee and proactively plan for these issues. Taking from those lessons learned, this article addresses a few of the challenges that you may face when implementing application lifecycle management (ALM) strategies.
Managing Software Development and QM Complexity
We all know that software development and QM is complex, has many variables, and is not an exact science. It takes planning and oversight to reduce the risk of things going wrong. Over the years, I’ve identified ways to mitigate many prickly issues. I start with good engineering practices, measure what I can, and make adjustments things go astray. Unfortunately, some developers have a much more reckless approach.
Running Behind Schedule
It is very common for projects to fall behind schedule–almost from the initial phase. The inability of the team to come up with realistic estimates may be a reason for this. To address this issue, you should first find out who is estimating the work, the project manager or programmers. You should be concerned If the project manager is doing the work estimation. Always allow the programmers to estimate their work because they’re more attuned to the essential duties required to complete each programming task.
OK, so your programmers are estimating, and they’re still running behind. At this point, we need to dig a little deeper. Are the requirements properly defined, and did the programmers take the time to draft a design when estimating? If not, they’re probably under-estimating because they did not decompose the requirement into low-level design tasks needed to fulfill the requirement. By getting into the weeds of the design, you can really start to estimate better.
Scope creep is another common issue. You start off with a design, start coding, and then someone comes up with some cool enhancements to the feature. So, you try to fit that coolness into the same work schedule when, instead, you should re-estimate the work based on the new features to ensure that they will still fit within your time constraints. If they don’t, let the cool feature wait.
Finally, some people are just not good at estimating tasks. You have optimists that like to think they can get more work done than they really can (I fall into that category), and some pessimists that sand bag by putting out huge estimates to cover their butts. Both of these issues are detrimental to a project, so determine who estimates well and who doesn’t. Find ways to improve their estimating skills. In addition, consider why projects take so long in the first place.
Why Do Releases Take So Long?
Let’s say you are working on a software project. The requirements were defined upfront, and it still took six months or more to began producing the software. How you got here may have. Maybe the estimated time to start production was six months or less, but things kept getting delayed until too many months elapsed. What the heck happened?
Whatever the circumstance, six months is too long to finish a software project. Projects like this suffer from what I call the elephant syndrome: How do you eat an elephant? One bite at a time. Hopefully, you don’t choke.
Staffing or quality issues may have caused delays, which I’ll address