Every organization I’ve worked for claimed to have a proven methodology. In reality, time and experience show that most organizations may be able to talk the talk, but they can’t actually duplicate their successes or failures.
I saw a classic example of this early in my career. The company I worked for established a good reputation as a deployment and operations firm. It had a variety of successful implementations under its belt, and many satisfied clients. I came in at the height of the company’s success, working on successful project after successful project. The technical team demonstrated a combination of customer service, intelligent deployment, and stable operations that created long-term business relationships.
Flush with success, my managers asked me to generate some substantial methodology. They knew that we couldn’t just run forward forever, trusting luck and the good intentions of the crew. Although I was one of the younger team members, I had a background in process, writing, and the all-important customer service.
I took the task seriously. For months, I studied project management, iterative software development, process design, communications theory, and management texts. I interviewed our clients, internal staff, and various CXOs of organizations we worked for. I rolled all the thoughts and good ideas I encountered into a massive set of templates, forms, and design diagrams. It covered everything from pre-sales questions to operations close-out procedures. I even included some presentations and glossies to help out the sales team.
No one used it. No matter how much everyone said they liked it, the documentation proved too cumbersome for the day-to-day operations of our projects. Our customers disliked it, too. On the rare occasions that they even saw it, the paper documentation either overwhelmed them or didn’t provide what they were looking for.
In the years since that first disastrous encounter, I’ve seen literally dozens of system integrators and consultants tout their methodologies. Most of these so-called methodologies are no more sophisticated than what I produced that first time. A few masquerade as complex theories but boil down to the same thing—a set of templates and massive documents that might or might not apply. I’ve seen rooms filled with nothing but old project documentation and technical design binders, all covered with a layer of dust that started gathering the day they arrived.
Methodology, not method
The problem doesn’t rest with the quality of thought put into those documents. Nor, for that matter, does it reside in their volume. Instead, it originates in the junction between theory and application that leaves so many of us uncomfortable.
When we talk about a methodology, we usually envision the deliverables: lists of risks, proven mitigation plans, ways of communicating key information in a rapid fashion. Sometimes we may talk about the level just above the deliverables, the process by which the actors generate the documents we want them to create. Occasionally, the very best of us include a method by which the deliverable templates are changed to meet specific customer needs.
Unfortunately the deliverables and processes that we focus on are not the methodology. Instead they are the products of the methodology, what we create to turn the world of theory into something practical. The process, only one step removed from the methodology, is the result of the methodology meeting the work habits and abilities of a given team and organization. The deliverables are one further step removed, the result of the interaction of the processes with the practical application and work required to execute the project.
Take a simple example. Theory states that projects exist to create unique products. Network design methodology states that to finish a project, it must be ready to hand over to operations. Therefore, you must explain to the operations team how various network components (access points, identity verification systems, services, and servers) interact. Process outlines how people on the project will contribute to the creation of this explanation. The explanation itself takes the form of documentation, either printed or electronic, formatted in a fashion to be most directly accessible to the specific customer.
Templates and similar objects have their place, usually as examples provided to the people involved in the process. They also help enforce a minimum level of documentation quality. The very best templates come out of documentation methodology separate from the design/deployment/operations methodology, harnessing communications theory to assist the team in presenting the data required by the technical methodology. However, the set of templates is neither the methodology itself nor a straitjacket—the templates can be changed to meet the needs of the client and the team.
Many years after my ill-fated encounter with methodology, I worked for another system integrator on another set of large projects. After a time, the senior technical staff and I sat down to come up with a “technical methodology” to help the junior staff. Our idea was to create a balanced perspective using our broad range of skills and expertise. Together, the team had about 100 years of development experience, and around 80 with infrastructure.
The team launched into a methodology development project, producing reams of pages and dozens of intricate process diagrams. We had templates for everything. After the initial frenzy settled, I suggested that we step back and lay out what we were really trying to accomplish. Our goals and statements of method filled all of a single page of paper. We then created a four-page explanation of those principles and further elaborations that would enable other people to create the process by which we derived the documentation. The resulting methodology was easily understood and explained by our sales force. It also moved into the operations side of the business, creating a shared language among multiple groups who traditionally had difficulty communicating.
In the first case, I focused very hard on the resulting documentation, never really cutting down to the core of the methodology issue. In the second, I worked with a strong team to generate a clear set of guiding principles.