At Lofty Labs, we help our clients build software products that elevate their business. A substantial portion of the value we add to our clients' projects is our structured process for managing and delivering results.
Why is that process so valuable to our clients? If you're working with a technical team to design a project, everyone seems to be spending spending most of their energy debating programming languages, which frameworks to use, and visual design choices right?
The reality is that there's a high amount of inherent risk in taking on a software project, and the factors that cause those projects to fail aren't necessarily as related to the technology itself as you might think.
How Risky is Software Product Development?
Are you sitting down? Check out the numbers from a large study of IT projects by McKinsey and Co:
Source: Delivering large-scale IT projects on time, on budget, and on value; McKinsey and Co.
In the projects analyzed by McKinsey, 2 out of every 3 software projects experience a budget overrun and 1 out of 3 projects experience a schedule overrun. Still, despite going over budget and over timeline, some portion of these projects still fail to deliver the expected benefits the project aimed to provide.
For professionals outside of the technology world, these numbers may come as a shock. The reality is that software development is a complex intersection of hard science and creative, making outcomes extremely difficult to estimate and predict. McKinsey goes on to attribute those failures to the following major categories:
How Much Does Process Matter in Building Software?
The primary takeaway here is that IT projects, particularly software projects, tend quite frequently to go poorly from a management perspective. Notice that technical complexity and lack of skills only represent 2 of the 8 identified causes. Yet it's in the technical minutia and skill qualifications where the vast majority of effort is expended when planning a project. Are you talking to a technical team or vendor about a project right now? Are they spending more of their time focusing on which technologies to use than the actual how of building the product? Read on.
To reduce risk, we can focus our efforts on avoiding the other identified root causes, namely the following:
- Unclear objectives
- Lack of focus
- Shifting requirements
- Unrealistic schedules
- Reactive planning
Why those in particular? Because those root causes are the ones that we believe can be eliminated with high quality process and systems. And, almost all of them are the direct result of too little investment in up front planning.
We're talking about an industry that is dominated by mantras like "move fast and break things," (which honestly has its heart in the right place--"Don't wait for all the lights to turn green before you leave the house," as one of my clients would say), but that mentality leads software teams to naively thinking the best thing you can do at any point while building products is to start writing code, right this very second, and plan as you go.
This philosophy is a bit of a knee-jerk reaction to the so-called "waterfall" method of software development where management attempted to roadmap every detail and minutia of a software product 24 months in advance. Things tended to go, well, quite poorly. These days software teams are much more likely to use a management philosophy like Agile. While Agile is a great methodology to use during the implementation and delivery phase of digital product development (we use it here at Lofty), too many teams mishandle Agile as to encourage "any planning up front is wasted effort--plan as you go," leading to disastrous ends.
How Lofty Engineers Success
Again, Agile is a great methodology and we use it during the delivery phase of our engagements here at Lofty Labs, but we begin every project with a discovery and planning phase that we call Ignition.
During Ignition, we build a long term roadmap and short term scope that bootstraps the Agile process. Through a series of structured exercises we work with our clients to truly understand the problems they aim to solve, discover the Critical Path within the product, and ultimately define the successful outcomes which we aim to achieve. If you recall the root causes of failure I highlighted above, this process is aimed squarely at eliminating unclear objectives and reactive planning.
After Ignition, we assemble a dedicated team to executing the project plan. This team is working full time on your product, because lack of focus kills software projects.
During delivery and implementation we leverage Agile, working in 1-2 week development sprints to prevent shifting requirements and unrealistic schedules.
The studies show that software projects trend towards failure across all organizations, but understanding the individual root causes of those failures allows us to create systems and methodologies that maximize successful outcomes.