Control and Management
The terms Control and Management are often used interchangeably for a variety of activities in product development: configuration, change, risk, process, and so on. From my perspective, there is a difference between the attitude (implied or expressed) with these words, and for a couple of reasons, I tend to lean towards management over control.
In the minds of most people, when we say we are controlling something, we see that as setting limits on it. Not letting it get too high (or too low), with the implication that if we let it get ‘out of control’ we have failed to do the right thing. While that might be appropriate for at least some aspects of some things (such as our speed when we are driving), those limits in many situations can limit our ability to perceive or appreciate the other side of the coin.
Management, on the other hand, doesn’t necessarily imply that the thing we are managing is bad, it means that we have a handle on it (I almost said we ‘have it under control’). This allows us to look at the situation in an often profound way.
Take dealing with risk, for example. Traditionally, we talk about risks as things that could happen on a project, and we keep an eye out for things that could negatively impact the project if they were to occur, such as a key resource on the project leaving. We consider the likelihood of this occurring, the cost to us if it were to occur, and we calculate the overall exposure. Do this for a bunch of risks, sort on the exposure, and we have a tidy list of our most dangerous risks that we can then start to mitigate as we see fit.
Almost all projects deal with risk in this way. Risk is bad, we want to limit it, and thereby minimizing our exposure to potential problems.
If we look at it from a management perspective rather than a control perspective, we gain new insights. There are some things that could happen to us on a project which, if they occur, would be a huge benefit. Imagine a project where we have a nasty algorithm to implement, and we don’t really have the right resources to deal with it. The uncertainty of whether we can successfully implement that algorithm can be significant for our project. Some way into the project, we discover an open source version of that algorithm that plugs nicely into our architecture. What we have here is an opportunity, and just as we need to be on the lookout for risks to minimize their impact, we should also be on the lookout for opportunities, so that we can maximize their impact on the project. We can have a hand in making our own luck.
Part of risk management (or would it be more appropriate in this context to be called uncertainty management, and remove that negative-sounding ‘risk’ word as well), then, should be to brainstorm the potential good things that could affect the project, and for the ones with the greatest potential impact, build strategies to increase the likelihood that they occur. In the example above, it might make sense to kick off a more exhaustive search for that pre-implemented algorithm.
While some may say that proactively trying to make the good things happen is the same as proactively trying to prevent the bad things from happening, but I see a distinction in attitude. Seeking opportunities is a level beyond trying to limit the risks.
Similarly, we can seek out positive differences in configuration management (proactively managing configuration streams to optimize development team efficiencies rather than merely controlling the number of streams that are branched off), change management (working together to proactively identify novel approaches to dealing with change, rather than naively trying to live to the original schedule) and process management (working to innovate and refine processes rather than trying to constrain everything to the same standard).
In the evolution of management, we start out as chaotic and unmanaged, and all the elements I talk about above are typically not managed or controlled, and hence we are simply in a reactive, defensive (and often failed) position. Often the next step is to try to ruthlessly control these things, and while we can limit the negative impacts (to some degree), we can often fail to respond to the world around us, and certainly fail to seize opportunities that may arise. Ideally, we want to have a level of mastery where we are comfortable in dealing with changes, and proactively seek to optimize our environment for the good of the project, in all dimensions. – JB