If your organization is experiencing disproportionally higher chaos on your larger projects, you might ask if you had sufficient information and time at the beginning to understand the problem being solved before anyone committed to cost or schedule targets.
I recently had an animated conversation with a colleague who is working on a project from hell. She first described the symptoms she was seeing:
She next provided some context; the consulting organization she was working for had a reputation for doing good work on small scale projects. They had a pre-sales cycle that involved potential customers in a workshop with the organization’s “architects” to flesh out an architecture, crude concepts of UI and UX, identification and prioritization of epics, and rough pricing that served as input to the bid process.
Recently, the organization had shifted their focus and was going after larger and more complex projects. The system my friend was working on was the largest and most complex that her company had ever undertaken. Ten minutes into the conversation, I recognized a potential pattern that has been at the core of several large system debacles I have observed in my career: failure to adapt the pre-sales (or pre-commitment) exploration process to address larger and more complex projects.
System developers face a daunting puzzle:
“How much should we invest in understanding the customer’s problem so that we can make informed decisions about how much the solution will cost, how long it will take to build it, and whether or not we want to commit to offering to solve this problem for the customer?”
Most development organizations start out building small and relatively simple systems: websites, utilities, small stand-alone applications, and modifications or extensions to commercial software. Although my experience as a software engineer and project manager compel me to suggest that all projects need a bit of systems engineering and project management, I concede that the degree of rigor required should be driven by the size and complexity of the project.
Organizations that cut their teeth on small/simple projects may be able to get by with less project management and systems engineering investment initially. They may experience early success while experiencing some low-level chaos, but smart people, long hours, and determination can allow these organizations to survive and thrive on small scale projects. Problems arise when initial success leads to larger and more complex projects, and the smaller scale analysis process isn’t up to the task.
One of the most likely places for the analysis and delivery cycle to begin breaking down is the initial data collection process. When contemplating and sizing a small project in a familiar knowledge domain, data gathering might be accomplished in a meeting or two with key stakeholders and a bit of research. The output of this meeting might be a high-level picture of the scope, necessary resources, and schedule needed to build a proposal for the client.
The challenge is that size and complexity do not increase linearly—if building a system of size X takes 500 person hours and 2 months it is dangerous (and usually incorrect) to assume a system of size 2X would require 1000 hours and 4 months. As systems get larger and more complex, the investment required to define and size the solution quickly grows beyond what can be accomplished in “a few client meetings”. As desired solutions’ size and complexity increase, they require a greater investment in preliminary design, architecture, and project management. Organizations that don’t recognize and adapt their initial assessment to invest the necessary resources tend to find themselves working on larger projects that are messier and more likely to fail.
“It’s not the process…” you will hear management lament, “…we used the same process on the last project, and it worked fine.” The focus (or blame) then shifts to the people doing the work who are clearly screwing things up somehow.
Important considerations include:
The up-front engineering and project management investment necessary to support business decisions about a project should be scaled to match the size and complexity of the project. Failure to do so leads to project and sometimes organization failure.
Does your pre-commitment planning include mechanisms to identify and quantify the size and complexity of the project? Are preliminary architecture and design being explored and framed before committing to cost and schedule targets for larger efforts?
When pre-commitment data collection is overwhelmed by a system significantly more complex than those it was designed to support, organizations fail to notice that at their peril. Before you commit to cost and schedule goals, make sure that your targets are clear.
Lets Hang!