Early in our career, we became fascinated with the process of developing software. Back then, we told the programmers what we wanted, and they went off to create it. Sometimes the software looked like what we had imagined, and sometimes it looked more like what the programmers imagined. It was hard to decide if the results were due to the limitations of software tools, or because the programmers created it to their design specifications.
Over the years, the process evolved to include more end-user involvement and more end-user sign-offs on both the design and the process, which has become a formalized approach called Agile. Agile incorporates users and developers (they’re not called programmers anymore!), into an accountable, iteration-driven methodology. The results have been remarkable, both in terms of user satisfaction and the quality of the designs produced. Not so much on the cost side.
There are three components of executing systems software: cost, time, and quality. One of our colleagues some years ago always started out the conversation with a new prospect by stating the three components, then adding, “Pick two.” His point was this: every project has constraints, and those constraints will impose themselves into one or more of those components. Need the software next week, and still want quality? Your budget just exploded. Want to keep costs down and still be ready for year-end processing? Quality will suffer. Want something incredibly complex? All you need is time and money.
It’s a fallacy whenever a software salesperson says, “Of course we can do that.” Well, of course they can! Software can create functionality to do just about anything. All they need is time and money. They’ve got the time as long as you’ve got the money. And plenty of it.
Which is why the Agile methodology is good, but it is also why it can fail. The Agile team is comprised of the technical side and the user side. The users are not adept at matching their desired functionality to the budget, and because the Agile process is based on iterations (time-boxed periods where specific functionality is designed, tested and put into production), oftentimes design components are removed so the iteration will succeed (functional software that is production-ready). Sometimes those components are put into the ‘parking lot’ for future reference, more often they are put forward into the next or a future iteration. The cost of the project expands, because the number of iterations needed to provide the functionality, both from the original estimates and from the Agile add-ons, also expand.
Our experience suggests the initial iteration scheduling anticipates certain areas of complexity, but as end-users get involved in the process, functionality that wasn’t considered a requirement at the beginning become so as each user looks to solve a particular problem or make the process ‘easier’ for themselves. Or, worst of all, the user tries to influence the design to make it more ‘familiar’, i.e., replicate the current process.
Any increase in complexity raises costs, but in every system implementation we’ve been a part, users will transition what objectively is a ‘desire’ into a ‘requirement’, regardless if it serves an actual business need. The implementation suffers, first, because it will extend the time and cost of the implementation, but second, it will provide complexity to the system that serves only a few, maybe even only one. That complexity is a hidden cost, because it will require institutional memory to maintain it, long after those users are gone.
Hence the question, what do you want versus what do you need? This question is THE critical step that some people miss when developing a software system using Agile, and as noted above the results can be disastrous to your budget, timeline and software product.
Someone needs to be the friendly whistleblower, to minimize the wants and focus on the needs. The ‘wants’ can become ‘needs,’ but someone who understands and is accountable for the evolving budget status must make a clear decision that that piece of functionality is appropriate and can be included in the project. Would you want to be that person?
At the start of the project, how clear is it to either the user or vendor (assuming it is purchased software), that, though the two parties start with a mutual understanding of the three components, there will come a time when only two, or, in the worst case, only one can be achieved for the remaining iterations? Who bears the responsibility for the loss of the other(s)? That’s where the tension will arise, because it inevitably comes down to time and money, or both. That’s when software implementation gets messy.
The solution often defaults to the vendor who must track every change to the original plan, and assign the impact on time and cost. This requires a great deal of vigilance! The vendor then becomes the bad guy.
And very few people want to continually be the bad guy. That kind of hyper-vigilance would drag the comradery and optimism to the point of acrimony. Every change becomes a negotiation to see who bears the cost- both explicit and implicit – the vendor or the client.
We’ve rarely seen that kind of vigilance work. There is always tension, there is always messiness. What should be a want becomes a need, and the user doesn’t see what will happen a few months down the road, while at the same time, the developer/vendor wants everyone to be happy. Being ‘done’ gets pushed down the road.
How strong is the bond between vendor and client? That will be key, because if the process is adhered to, and all the ‘costs’ are fairly and reasonably communicated, the client will get more than what they need, and the vendor will profitably get to ‘done.’
~ Bill Montei, CEO, founded Megalodon Insurance Systems with a simple yet BIG idea: provide small and mid-sized captive managers and re/insurance companies powerful policy, claims & billing management software solutions at a price that is within reach. To speak with Bill directly, please call: (800) 406-5551.
