Let there be light!

Back in the mid ‘90’s I had the opportunity to establish and lead a small software development company named Strategic Innovations. Initially Strategic Innovations focused on application development via Visual Basic. But as the ‘90s progressed we naturally expanded our expertise to include Internet-based application development via Java and ASP technologies. In 2000 I sold Strategic Innovations to a Midwestern company, Meritage Technologies, who was rolling up small Microsoft-focused software consulting companies in key markets in hopes of eventually taking the company public.

One of the first projects we landed after being absorbed into Meritage Technologies was a job to develop a Java application to enable Fortune 500 companies to manage their global Six Sigma efforts. This application was truly innovative in concept but the project was a nightmare and by most measures a failure. A solution was ultimately delivered but it was over budget, under scope and late.

When I eventually had the luxury of assessing the project I identified several key circumstances that when taken in isolation did not cause the project’s failure but when combined together they created a ‘perfect storm’. Some of those circumstances were:

• The application was 100% conceptual and there was not a point of reference to draw upon within the client’s business or even the general marketplace.
• A monumental effort was undertaken by the business analyst at the beginning of the project to elicit and define the envisioned application’s full set of functional and technical requirements.
• The requirements were well documented and placed immediately under change control.
• Development was “outsourced” to a sister office in another state at the request of corporate management.
• The business analyst was the sole interface and intermediary between the client and the remote development team.
• A significant amount of requirements churn eventually stymied and all but paralyzed the development team and its progress.
• Once the requirements began to churn the project became a bureaucratic mess due to a rigid change request process and an overarching focus on the project plan.

It was not until a few years after this project that I was able to start to correlate these circumstances together and begin to comprehend their association and collective contribution to the project’s failure. It was also at this time that agile methods started to gain traction in the development community as an emerging development mindset and alternative to the typical waterfall approach. I can still remember reading the Agile Manifesto and having all kinds of bells and whistles going off in my head as I reflected upon the principles behind the manifesto. It was an epiphany and a key watershed moment in my professional career.

Working software over comprehensive documentation

Since the project was truly a ‘greenfield’ development effort the expectation that the client definitively define the application’s requirements at the outset was completely and utterly unrealistic. It isn’t that the client didn’t have a clue about their business but rather they had no point of reference to draw insight or knowledge as to exactly what needs the application was to fulfill. Thus the requirements that were initially defined and well documented essentially became worthless once development got underway. The only thing that would have enabled the client to more fully understand their needs and the application’s requirements would have been working software that they could have touched, felt and played with.

Customer collaboration over contract negotiation

The primary reason why such a huge effort was undertaken to capture all of the application’s requirements upfront was because both parties “needed” a defined scope to build a contractual agreement around. Once the contract was in place a rigid change management process was enacted to ensure the contract’s integrity as well as to facilitate mutually agreed upon scope changes to that contract. Yet as pointed out previously the client had no frame of reference to draw upon when defining the application’s requirements and thus the contract was, for the most part, based upon an ill-defined scope and a premature set of requirements.

The result was that collaboration with the customer was essentially squelched. Why this happened was because as the application became more tangible in the client’s eyes, the more clarity that was realized about the application’s true requirements. Yet that clarity necessitated endless change orders as well as addendum to the contract. Eventually whatever collaboration and trust that had existed disintegrated into an ongoing negotiation and renegotiation exercise.

Individuals and interactions over processes and tools

Outsourcing development to a sister office was a corporate mandate in an effort to help offset the economic downturn experienced by this sister office as a result of 9/11. This decision decimated any semblance of a team as well as effectively prevented meaningful collaboration and cooperation between the client and development team. This separation eventually contributed to mistrust between the business analyst and development team as delivery dates slipped and confusion surrounding requirements prevailed. Combine these circumstances with the previously discussed challenges and it can be seen that close, daily cooperation between the business and technology team is essential.

Responding to change over following a plan

Given the nature of this project as described above it can be plainly seen that change was inevitable on this project. But in every facet of the project life cycle, change was considered the antithesis to the project’s success. It was to be eliminated and avoided at all costs. The reality is that change should have been fully embraced and enabled throughout the life cycle and within the disciplines of the project. Yet both the client and development team were incented both contractually and monetarily to keep to the plan regardless of whether responding to change would have helped ensure the success of the project.

Conclusion

It was this project experience and resulting soul searching that prepared me to fully embrace agile when I took the reins of software engineering at Graebel back in 2005. Yet over the last few years we have not only embraced agile for our new development efforts but have expanded our agile mindset and disciplines to encompass all of our software engineering activities from maintenance, support, minor enhancements, major enhancements, architecture, infrastructure and large capital projects. We have also incorporated business analysis and product management disciplines with the goal of quickly expanding into program and portfolio management disciplines.

Future posts will bring insight into our current processes and disciplines with a look to the future and how we plan to continually improve, reduce waste and journey further into what we call enterprise agile.

Advertisement