Originally published on LinkedIn on 17-Jun-2016 (Process Standardization, Metrics, Agility et al.)

Information Technology organizations strive to create and maintain standardized processes that represent the organization’s unique identity, culture, geography, business domain, technology focus and people. An organization understandably evolves its own culture, but this culture varies with geographies, projects, teams and floors. Even if the business domain remains same across geographies, we have different requirement areas involving, at times, vastly varied industry knowledge. It is theoretically possible to have all projects employ the same technology and people, but it is not practically feasible. So when each project and program within an organization has its unique characteristics, applying a standard approach to execution cannot be a solution. So where does this leave us? “To Standardize or Not” is the question then. Or rather what should we standardize?

Let’s dig a little deeper. Standardization is inherited from the traditional software development world. It’s become a norm to create a standardized process, leaving little room for configuration per specific context. The argument is that without standardization of the process, each team and project will follow its own process which will lead to not having a consistent mechanism of tracking and reporting. A standardized process creates a false sense about the organization’s goals. Can the goal be to have a system, which enables the management to measure every project’s progress with the same yardstick?

Of course not. So what’s the goal then? Let’s examine this in detail.

1. Goal: Regardless of the industry it belongs to, every business has a goal to roll out new products and services or to grow the existing products and services. There can be some variations, but this can be a fair generalization of the goal.
2. Metrics: To assess the progress of the organization in reaching the goal, it needs to have some metrics based on which certain decisions can be taken. The parameters on which these metrics depend, vary across multiple dimensions. And these parameters can be different for different organizations belonging to the same industry.
3. Plan: Once the metrics are identified, these need to be measured continuously. There has to be some mechanism to plan and track the work which goes towards achieving the goal. This mechanism largely depends on the metrics identified for measuring the progress.
4. Process: The mechanism for planning and tracking the work will give rise to a process, which will include different practices, workflows, tools and techniques. This will certainly depend on the organization and project context.

In short, the process being adopted depends on the metric identified to assess the progress of any initiative. If the identified metric is common across initiatives, then yes, the process can be same or similar. But, this is rarely the case in practice, as no two initiatives are exactly similar. This means that the same process cannot be applied to all initiatives within the enterprise, which further means that the traditional mindset of process standardization needs to be re-looked at, if the business wants to gain competitive advantage by rolling out new products/services quickly.

This certainly applies to today’s software development world where the line between the Business organization and IT organization is fast getting extinct. Some would strongly argue that without process standardization, it would be really hard to create a new process for every initiative the organization is embarking on. Why do we need to re-invent the wheel for every vehicle we are developing? Well, the wheel may not be re-invented, but the dynamics under which the vehicle is expected to perform will lead to re-designing not only the wheel but each and every component of the vehicle.

So what’s the way out? What’s the answer to the question “To Standardize or Not”? There needs to be standardization, not of the process, but of the philosophy which goes behind designing the process. In other words, we need to have a set a Principles which can guide us to work towards our goals. Yes, you are right, this is all philosophical and needs a lot of thinking and investing your efforts in the right way to achieve your goals.

And which tools can help us in this, you may ask. There are many and these tools have proven themselves multiple times over the last couple of decades. Lean Thinking, Theory of Constraints, Agile Manifesto and Design Thinking are some of the philosophies (out of many) which help you think creatively and act productively. The only catch is not to treat these tools as “standards”, but use them as a guiding light for your organization’s initiatives.

Let’s take an example of Agile software development. To start with, we have the Agile Manifesto, which is a set of Values and Principles. And then we have numerous frameworks, methodologies and practices. If an organization decides to follow the Agile Manifesto for all software development initiatives, the decision to design the software development process needs to be decentralized to the team which executes the project. Now, this needs a lot of thinking effort on part of managers and team members. This is where frameworks, methodologies and techniques like Scrum, Extreme Programming, Kanban, SAFe etc. help in process design. Again, if we use these frameworks and techniques as “standard” processes across the organization, the essence of Agility is totally lost.

Finally, the primary objective should not be the process adopted to measure some numbers. The primary objective should be to achieve the organization’s goal by adopting a sensible and relevant process.

Disclaimer: The opinions expressed in this post are the author’s own and do not necessarily reflect the views of the author’s current or previous employers.