Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
HealthCare.gov Shows 4 Ways Software Delivery Must Change
Troubled project should encourage you to discard traditional manufacturing processes with their reliance on control, and prioritize information and flexibility.
5 Min Read
(Source: Flickr/Drew Stephens)
In my last blog post, I discussed how the launch of the Affordable Care Act's healthcare exchange website illustrated how modern software delivery has reached a point of complexity where the current processes are failing, and management practices must change. These processes have taken their direction from traditional manufacturing and supply chain metaphors, where the mantra has been "When problems occur, add more process and control."
But software today is a complex product that involves a multitude of suppliers and technology platforms. That's why those who manage software development must look to nature and think in terms of ecosystems as a guide to their process models. We must consider discarding traditional manufacturing processes, with their reliance on control and process, and replacing them with information and flexibility.
[What does the HealthCare.gov website reveal about software development? Read Healthcare.gov Shows Need For Modernizing Software Delivery.]
You can never predict what will happen during a software project, but you can determine the measures you need to see as it progresses, and you can connect the software development supply chains to deliver those measures. By putting the right measures in place, the prime contractor and the ultimate customer can see how the project is progressing and react to any missing integration and performance testing phases by changing the deadline or altering the project's scope.
Specifically, the lead software delivery team should do the following:
Build out measures and reports that help the project team understand the project's true status. These reports must include development metrics such as quality and progress, as well as customer metrics such as usage and happiness. They should aggregate the results of progress into an overall portfolio view, allowing executives to make investment decisions in real-time.
Ensure that the teams have a clear understanding of all the dependencies affecting the project. This includes outsourced testing or external development teams. There are more complex dependencies, such as vendor APIs and open-source projects, which are often known only to the developers and architects involved. However, all dependencies should be visible enough to manage the software project effectively.
Manage the entire lifecycle, integrating all dependencies. By automating and integrating information about eternal activities, a software development team can assess the overall development picture more accurately and act proactively, instead of waiting for reports to reach their attention.
For many software development professionals, this approach to project management seems both scary and expensive. After all, it takes organizations years to learn how to integrate, manage, and automate their supply chains. But here's where the very nature of software delivery provides an advantage: With the advent of agile development and engineering improvements such as continuous integration and automated testing, development teams are becoming more disciplined.
Increased discipline, combined with network infrastructure and the changing style of collaborative and task-based development, provides an environment that is ready for a more structured but less enforced approach -- and that approach is neither scary nor expensive.
Here's a call to action for software delivery professionals:
Accept that controlling your own teams is hard enough, and that the reality of modern software is not about control but information. Process has been replaced with observation, and control has been replaced with adaption.
Consider which measures project teams need across the lifecycle. Those measures should focus on internal metrics such as budget and variance, as well as external metrics such as customer feedback.
Map out all lifecycles to reduce development risk and react in the most appropriate way. Not all dependencies and lifecycles are equally important. Some are slow to change or are less critical.
Automate the integration of different lifecycles, focusing on the key measures and metrics required to respond and adapt. For instance, integrate with the defect repository of the open-source project on which the product depends, or with the defect repository of a popular API. For external project dependencies inside the firewall, it might be possible to access the requirements and project plans, allowing a forward-looking view. Even external connections to tools like Stack Overflow or to wikis might be helpful.
By embracing ecosystems, government software project managers can not only improve transparency -- a core goal of the current administration -- but also increase the overall predictability of the software lifecycle. Concentrating on measures that use real data, such as build stability and CI test runs, and bringing end-user feedback into the process quicker will help bring more transparency to the project -- and ensure that the team is aware early if a project is failing.
There's no silver bullet for solving software delivery problems. The ACA website is just one example of a software project failure. But as software development professionals, we can improve our understanding of projects and employ true measures for success, instead of concentrating on rudimentary artifacts and reports that exist solely to manage the process. By combining improved, integrated information and more timely customer feedback, government agencies can follow the proven path of Internet giants like Amazon, Google, and Facebook.
Dave West is chief product officer at Tasktop. He is a frequent speaker at industry conferences and a widely published author of technical articles, including a book on object-oriented analysis and design.
Emerging software tools now make analytics feasible -- and cost effective -- for most companies. Also in the Brave The Big Data Wave issue of InformationWeek: Have doubts about NoSQL consistency? Meet Kyle Kingsbury's Call Me Maybe project (free registration required).
About the Author
You May Also Like
More Insights
