Scope, schedule, and budget. Perhaps no other concept is as deeply driven into the heads of young project managers. It is the iron triangle. The triple constraint. Scope, schedule, and budget define project quality.
However, the iron triangle fails for in-house DevOps teams.
Consider the following scenario. An employee needs a simple AR aging report. Such reports have been around forever, so the scope is tightly defined. The development team comes in and specs the project. They say two weeks. The project manager promises three weeks. The project comes in at two and a half and produces a flawless AR report. In scope, on time, and on budget. That is a success, right?
Now fast forward a few months. Support gets a call that the aging report is blank. But accounting knows that there are old invoices. Clearly, something has gone wrong with the report. Support starts digging into the problem. There is little to no documentation. Hours are wasted trying to ferret out the logic of the reporting process. It turns out to be a simple error in the inputs, something that could have been caught with some defensive programming. Hours more are spent in addressing the source data.
The actual but perceived quality of any deliverable varies over time. The AR aging report was a success on day one. But it was a failure when it was blank a few months later. Assuming the underlying issue does not get resolved (ie, the code bug lingers in input validation), the problem will continue to periodically occur. Come a year or two down the road, the business owner will complain that the aging report is junk and a new project will be started.
In this scenario, we have a simple logic flaw. Worse, assume the program was written without any security controls. Now all someone has to do is insert a check request in the unprotected source data, and create a fraudulent check. Though well within the iron triangle, such an aging report will contain operational and security concerns.
In the beginning, a project manager or a team manager can score a number of successes by strictly meeting the triple constraint. Each success, however, adds to team’s technical debt. I have seen many teams fail because of such successes.
With separate teams, such debt is someone else’s problem. The development manager has a string of successes while the operations manager is spending increasing amounts of time tracking down glitches. With a DevOps team, such debt is everyone’s problem. This means developers end up spending most of their time troubleshooting and patching old code. Development efforts slow because of this friction. Pretty soon, the business is wondering why it takes so long to get anything done.The solution? First, for in-house development efforts, cost is fixed. We are going to pay our folks regardless if they spend most of their time in support or most of their time on new functionality. Schedules are flexible and can be driven by the team. And scope, scope must explicitly include quality aspects driven by operations and security. That is to say, the project must be secure, it must be sound, it must be supportable, and it must meet the business owner’s needs.
Looking back at the AR aging report scenario, I would propose the following. Take the developer’s original estimates. Include estimates for code review. Include time for security review, and for hammer testing the application. Include time for documentation and other meta tasks. Perhaps that now boosts the time for the report from three weeks to six weeks. The project manager may not score a quick win. However, over the lifetime of the report, the business will see this report as more reliable and as higher quality. Further, over time, fewer hours will be required to support broken software. More time will become available for implementing new functionality. Build new functionality to a high standard and we create a positive feedback loop. That loop is key to delivering sustained business value.
Delivering sustained business value requires thinking outside the triangle.
Posted by