You gave me what I asked for, but not what I wanted! (Part 1)

Imagine the following scenario: You are the project manager ready to deliver the new system that your team has developed over the past two years. Millions of dollars have been spent in those two years to collect requirements, define the system, build an architecture and models, create a work breakdown structure and project schedule with resource allocation, build the system components, integrate, test, validate , solve problems and finally the day is near: delivery. You deliver the system with a lot of fanfare and you are confident that it will deliver as promised: greater efficiency, cost savings, improved customer service and increased revenues.

Your systems engineering team has done a great job of gathering and researching the requirements of the users, customers and even the “C-Suite” group. Everyone agreed that the requirements were well defined and dictated what the system should do. Your enterprise and system architects have defined the architecture based on the requirements, built models of the system, and reassessed them with stakeholders. A final design was developed and handed over to the development team for implementation. The development team tested their components for working and validated them against the requirements. After any discrepancies were corrected and the regression tested, the system components were handed over to the integration team to “bond” everything together. Again, more tests and validations have been completed, issues resolved, regression tests completed, and the system packaged for delivery to the stakeholders. Your work is done, and a promotion and a raise will certainly be in store for such a complex project.

Except … it quickly turns into a disaster. The users start to use the system and find that it doesn’t do what they thought it would. Processes are radically different, data management requires a new set of skills, some people are overloaded with activities, while others are now doing nothing, the newly formed help desk is inundated with phone calls and problem tickets, customer service takes a beating and the C-Suite quickly finds out. junk you have delivered. They order that the system be removed and restored immediately. Instead of that promotion and raise, you look at the real possibility of termination and no income at all. What you quickly learn by doing a “post mortem” on the project is a common problem in gathering and managing requirements: the stakeholders will say, “You gave me what I asked for, but it’s not what I wanted ! ” Somehow, the roles of project management and systems engineering should have been described as “mind reading” rather than gathering, structuring, and examining requirements for a system. But was it the inability to read minds or the process that led to this fiasco?

Before going any further, let me quickly define what I mean by “system”. Most people reading this article assume that I am talking about software. In many cases, the system that falls short of customer expectations is a new software option. In business, these systems can be custom applications developed for a very specific capability; In many cases it can be an Enterprise Resource Planning (ERP) solution based on applications from SAP, Oracle / Peoplesoft or Microsoft Dynamics, just to name a few well-known ERP solutions. However, a system can be anything: an airplane, a ship, a spacecraft, a car, a power plant, medical equipment … basically anything that meets the definition of ‘a set of interacting or interdependent components that form an integrated whole. to shape . Think of non-software-based systems that did not perform as promised or suffered delays and cost overruns: the Ford Edsel and Pontiac Aztec, which were market failures (requirements developed in a market vacuum), the Airbus 380 and Boeing 787 (requirements and implementation mismatch), and the Littoral Combat Ship (LCS), just to name a few.

Now that I have defined what a system is, I want to return to the fictional but very familiar story I created for the introduction to this article. I asked whether project managers and systems engineers should read minds or change the process to avoid the disaster. It turns out that mind reading is too not a prerequisite for each of these functions. What could have prevented the problems is the use of chaos theory and emergence as an approach to systems development. These theoretical constructs are the drivers for Agile development, and I will provide an overview of how Agile methods work and how they are implemented.

Agile development including techniques like Scrum, eXtreme Programming (XP) and Design Systems Development Method (DSDM) are rooted in the idea that the end users should be involved in the whole development process and that no one really knows what the end state of the system will be look like this: the final state arises from the whole process. This article does not discuss how to implement an Agile process; rather it describes some important aspects of the approach and why it works.

Agile methods are fundamentally designed to facilitate communication between all stakeholders in a project. The processes encourage teams to evolve as self-organizing systems, where people assume roles based on their strengths and interests. Communication is facilitated with “information radiators” that let team members post their progress and problems in a “war rooms” schedule board with Post-It notes. It also recognizes that end users of the system both play an important role in development and only really know what they want when they see it. This encourages the development of small, incremental solutions to a problem, instead of a monolithic solution that often does not satisfy anyone.

It is the antithesis of how organizations typically operate, as there is much unpredictability in what the final system will look like and the apparent lack of control during the development process. In addition, Agile processes tend to have sparse documentation: “decorative” document results, which do not add value to the team’s ability to develop and deliver a solution, are almost completely eliminated; much of the text-based documentation is replaced by diagrams, models and storyboards. Metrics collected are more focused on keeping the team on track of what’s completed and what’s in the pipeline, rather than the classic Gantt chart progress reports and earned value data that management is always focused on . Instead, daily “standups” are held: these are short meetings with all team members to discuss three things: performance, today’s goals, and roadblocks / issues to be addressed. Team members include the developers and end-user representative, testers, user experience developers, and testers.

The focus is on delivering small incremental bits of functionality rather than a large, monolithic solution. Remember, the users are getting things done without new systems so even small improvements in their operations will be appreciated. And because they helped develop it, they will rely on its success. Interestingly, there is no prediction of what the end product will do: As needs change, people change, and missions change, the incremental approach causes the system to evolve as it develops. With this approach, the problem of “You gave me what I asked for, but not what I wanted!” belongs to the past.

In part 2 of this article I will discuss why an Agile, incremental and adaptive approach works, why the old ways of doing business so often fail, and how the approach can be sold to a C-Suite staff who want a predictable end result . state, lots of statistics on the way and lots of documentation.