March 28, 2013
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 could 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 de-emphasize 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. Seapine's TestTrack, for example, supports multiple processes including various implementations of Waterfall and Agile. Rather than enforcing a particular approach, TestTrack can be configured to take into account team and project needs and work styles. But project processes need to be flexible to account for unique skills or professional development of the individual, as well as to account for 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. Don’t underestimate the power of people to do good work within any defined process. And don’t be afraid to challenge people with tasks outside of their core competence. They may fail, or they may gain the skills and confidence to seek out the next level of employment. That’s why they call it a career.Email sign up