Do You Have a Process, or Do You Depend Upon People?

There was a time when the answer to this question was very different than I hope it would be today. In the 1970s, the theory of systems management purported to tell project managers that they shouldn’t depend upon the unique skills and dedication of individual people, as those people could leave the project. Instead, they should define work processes that depend upon a skill class, rather than a unique skill. That way they can hire skills within that class, rather than look for particular or specialized qualities in individual hires. Often management didn’t understand how to value or manage people’s skills, so if they didn’t fit into the required category, they were discounted and even avoided in working toward team goals.

There is something to be said for that, but it has a couple of problems. First, all people do have unique skills, and many of those skills can be helpful in different work situations. Second, people need to be challenged in work, to develop and refine new skills that enable them to improve professionally. Management needs to find a way to do that, or the project stagnates and key people leave anyway.

What does this have to do with software projects and software testing? In software projects, management is typically rewarded based of the success of the process. At least, the process is the acknowledged reason for successful completion of a project. It is simply natural in an organization for a manager to credit his or her abilities and process for producing a successful result. And compensation comes from delivering results irrespective of the people involved, so management tended to deemphasize any significant individual contributions.

However, people do the actual work in the process. Managers depend on the people doing the work to keep to the process; however, they also depend on individual contributors to do whatever it takes to complete a finished product, whether or not it’s in the scope of the process. Testing consultant Matt Heusser refers to situations where the process fails as “the killer app”. How the people involved respond can be the difference between success and failure.

Process remains a good thing, in that it provides a baseline so that all stakeholders understand their roles and how those roles work together to achieve a greater result. A well-defined process can also be a project requirement if the project is in a regulated industry such as health care or aviation/aerospace.

But project processes need to be flexible to account for unique skills or professional development of the individual, as well as to unforeseen circumstances that require individuals to react on their own initiative to effect positive results. If a person with needed skills or better perspective can use the process for better results, or fix the project when the process can’t, that person must have the ability to do so. The project will benefit, and the contributor will feel good about it.