The “P” Word



Why is it that anytime the word “process” is mentioned, it seems that everyone turns tail and runs…?  It never fails.  I think that people, quite frankly, are scared of the word “process.”

Why would this be, you ask (assuming, of course, you have not run away from this page…)?  Well, I think it’s because it carries a certain weight to it.  And more often than not, people associate another word in the same breath as the “P” word: “formal.”  Even if no one mentions the “F” word, people automatically assume that process really means “formal process.”


“Formal” and “Process” need not go hand-in-hand. It’s nice if they do, sometimes, when it’s required or needed.  But these two words are not like swans, partnered for life.

I recently put out a proposal for a potential client that included functional testing and performance testing.  Knowing that this client is a start-up, I knew that they wouldn’t have much by way of defect management, environment management, or change management.  So, I included in my proposal that I would help them establish some lightweight process around these three areas.  In my mind, I was thinking of very simple things—a spreadsheet for defect tracking, a spreadsheet for change control, and some basic agreements and communication plans around identifying who’s using which environment and when.  (By the way, when I said “start-up”, I really meant two people.  Implementing a defect tracking tool for a 2-3 person company is overkill in my opinion, hence an Excel spreadsheet.)

In my discussions with the potential client, I mentioned a “lightweight” process and light documentation.  In the Proposal, I also mentioned “lightweight” process.  However, in negotiating the Proposal, the client’s response to me was that they didn’t think they needed “formal process” until they were up and running for about a year.

Now I have two fundamental issues with this statement.  The first is that I never mentioned anything about “formal process.”  The second is that the client didn’t think they needed any process for a year.  At least.

Process.  What does it really mean to have it?

Here are some definitions I pulled from a Google Search from various sources:

  • A series of actions, changes, or functions bringing about a result
  • To put through the steps of a prescribed procedure
  • A series of actions that produce a change or development
  • To subject to a routine procedure

To me, none of these definitions seems arduous or stringent.  Or formal.

Here’s my definition.  This is also the definition that I shared with the client.

Process is simply a set of agreed-upon and communicated procedures for accomplishing a specific task or tasks.

That’s it.  If the task is fairly straight-forward and is only performed by a couple of people and/or affects a couple of people, then a simple, straight-forward process should do the trick.  List some agreed-upon procedures on the back of a napkin, share it with everyone that would be affected, everyone agrees to it, and by golly, you have yourself a process!  That’s not too formal, is it?

I don’t think so.

On the other hand, if you have a complex task, set of tasks, or set of sub-tasks that must be worked on or completed together, and there are many people involved in doing the tasks, and there are many more people that are affected by these tasks, then it’s a different story.  The more complex a task is and the more people that are involved in it typically requires a more formal process.  It should be well-documented, communicated, and easily accessible for reference.  There may be many components, thus adding to the complex nature of the task.  In this scenario, a “back of the napkin” process probably won’t do.  This is where a more formal process is needed.

In the case of my client, I explained my definition of the “P” word and hope that they understood.  They are already following a process—they just don’t call it that. It’s currently just a process communicated between two people, probably verbally or via email.  But they’re following their own process nonetheless.

So next time, you hear the word “process”, don’t cover your ears and start singing, “la, la, la, la, I can’t hear you…”  No.  I want you to look at the person who said it.  Yes, look at her—right in the eye.  And ask her what she means—exactly—by process.   Does she mean simply agreeing to and communicating some procedures to get to an end result?  She’ll likely say yes.  I’ll bet you that’s all she wants to hear.

What do you think?  Do you agree or disagree about having process?  What about informal or formal process?  Let us know your thoughts!  We want to hear from you!


This entry was posted in blog, featured, IT process, process, quality assurance. Bookmark the permalink.

20 Responses to The “P” Word

  1. natasha says:

    maybe you could come up with a different, more fun and less threatening name for process for the smaller clients? just a suggestion…

    • vareynolds says:

      Thanks, Natasha! We could coin a new term or phrase…any suggestions?

      • natasha says:

        i would leave it up to you. i think you’re very good with words ;) keep it light! this might help to keep your smaller clients at ease. it would most definitely help me if i were in their shoes. if you could come up with a few words and post them here or on FB, your friends and clients could help you to pick one…

  2. Hemal Trivedi says:

    Hi Virginia,

    I want to share a similar experience wherein I got the opportunity of working for a startup company. The client was a one man company and he had outsourced the entire Product development project to my company. There were 2 developers assigned to this project initially and 1 tester (me) introduced later on. When I started, the first thing I observed was lack of process (by process I am referring to the same “lightweight” processes you talked about). No common or consistent method of requirement gathering/understanding, no defect mechanism (believe me, when I joined the project, defects were managed through emails, not even in Excel!). And this project was one which I took up after I had left a CMMI Level 5 company! I was just shocked to see the chaos. But I knew that I had lot of work to do in the project, not just in terms of testing, but also bringing in some order. First thing I started was tracking the defects in Excel. I let the client get used to the defect tracking sheet I used to send. Then I brought in color coding to identify defects in different status by background color. Then came in Pivot Tables which I called Summary, containing basic categorizing of defects by status values, severity wise defects , functionality wise defects and so on. Needless to mention, the client was very happy to see these reports as it eased his task of not only following up with developers but also reporting to his end users.
    During this exercise I never mentioned to the client that I plan to introduce any process. I just did it and the client happily accepted it. It was all bonus for him because he never expected this. But more than that, I feel he himself realized the importance of order and organized approach of tracking information. After one month, I asked him if we could bring in a similar order to requirement exchange (like sending requirements in Word document and versioning the document) along with query tracking sheets containing queries asked for requirements. Guess what was his answer! He willing agreed to it! Because by this time, he himself knew how valuable this approach would turn out to be.
    In the end, these changes or processes were then coined as “Value addition” to the project and the Client acknowledged it happily.

    To conclude, I agree there are many people who dont like the term ‘Process’. But there are others who like & even appreciate, if someone else takes the first step for them.

    • vareynolds says:

      Thank you, Hemal, for sharing your experience! I agree—introducing small improvements at a time often show, or prove, their value to others. This allows you to more easily introduce new concepts or “value additions” (great phrase!). Thanks for sharing. Please stick around and comment on our future blog postings!

  3. Kartikey says:

    Hi VA,
    Really good article. Indeed people run away when the “P” word is used..And the truth is unless we have defined “Processes”, it would be hard to Analyse, Measure and Synthesize the results.

    In my viewpoint, a less threatening probable alternate to word “Process” could be “Guiding Principles”..something phrased like this may sound better
    “I would help you with some guiding principles around testing area which in turn benefits you meeting your business goals effectively”
    Its really difficult to change people’s perception and their fear towards “P” word.

    On the contrary I have seen some clients who are really aware about benefits of Processes in their organization as well as strive towards being more process oriented.

    Wish you good luck.. and keep blogging..!!

    • vareynolds says:

      Thanks, Kartikey! I like the phrase “guiding principles”. Thanks for the good luck wishes–I’m going to try and blog more often and more regularly, so please stay tuned!

  4. Dan says:

    Virginia, you are so correct. It has always been humorous to me that everyone hates, even fears, the word “process” while at the same time nearly everyone I have ever met or worked with want order and sanity in what they do. So, they do want process they just don’t want that heavy process that people think they have to have to call it a “process”. I think some of this comes from the fact that when processes are designed and “formalized” by writting them down, people get this idea in their head that they need lots of words and strict rules. Generally this seems to lead to burdensome documented processes that people then work real hard to not follow.
    There seems to be something about processes that make them easy to over design, over document and gold plate.

    • vareynolds says:

      Hi Dan! Thanks for your feedback. YES! Putting a process on paper, for some reason, “formalizes” the process. And then scares people. Yet, at the same time, as you stated, people want order and sanity. Order and organization are driven by refining steps taken to achieve a goal or complete a task to make the steps efficient. Once efficient, then further refinement is taken to make the steps repeatable. Everyone does this in their daily routine, let alone in a work environment. By having a simple process, I’m able to shower every morning when I’m half-asleep—I’ve already honed my steps and the order in which I do them to make them efficient and repeatable. I haven’t formally written this process down, but I follow it every day. It makes me laugh as well, when people fear process.

      Thanks again for your comment. Check back every week or so for my new post—your comments are welcome!

  5. JeanAnn Harrison says:

    I am wondering if the Agile world has affected the process world to the point of avoiding documenting and promoting more and more of the rapid fire projects. Projects supposedly get done faster, perhaps with excellent quality, perhaps not. But what I’ve seen with developers is a trend of wanting to work in the Agile world because it’s an excuse to not be required to write up things like design documents and/or detailed software requirements. These developers then may move onto another project/company and continue with their preferences rather than adopting a culture that have some sort of formal process but isn’t clearly defined. Then when you have these developers convince management “hey we could get this development work out faster, let’s switch to the Agile way of doing things when really they don’t even understand what Agile Methodology means. I worked with a developer that tried to convince me that him not having to be responsible for any document writing was Agile. When I asked him if he read the Agile Manifesto, he said no but he didn’t need to do so. Hmmmmmmm…..

    Just some quick thoughts based on relatively recent experience.

    • vareynolds says:

      JeanAnn – Thanks for commenting! I agree—I think that Agile as well as RAD both have had ripple affects on overall software and application development, in terms of changing the views on what used to be deemed as “formal process.” Many organizations have done away with the old school waterfall method and instead have adopted what they think is Agile. Unfortunately, many folks say that they work in an Agile shop, when in fact, they do not. To paraphrase Ian Walker’s comment (found on LinkedIn Groups: Software Testing Club:, “a morning scrum does not an Agile project make.” Agile done correctly, following the premise of the Manifesto, and utilizing the, ahem, processes that allow Agile to be Agile can be a very successful way of delivering software/applications/systems. Reams of documentation are not needed in order for a project to be successful, but I think enough information needs to be communicated to get the project developed and have it be maintainable.

  6. Dave A says:

    C’mon now, the “P” gets a much better rap then the dreaded “B” word….” bureaucracy”. The “B” word is all about implementing the actions of an organization in the most efficient way possible, but alas, the “B” has come to encompass ‘Bloat’. Folks simply run for the hills when the “B” word is uttered, yet both “P” and “B” are joined at the hip (throw in “J” and you’ve got yourself a nice sandwich, but I digress..).

    Fact is: While the absence of either is chaos, too much can stifle creativity and innovation, grind your projects to a halt, and crush morale.

    The trick is finding the ‘process sweet spot’. This is not an easy thing to do. One needs to consider the size of the project, the size of the team, skill of the players, corporate culture, tolerance for risk, time and budgetary pressures, and a whole host of other factors, in order to tailor P&B for the job at hand. It’s very hard to get this right. As a result, many organizations will adopt a one-size-fits all approach, or maybe a ‘here’s 3 or 4 sizes – choose the one that fits you best’, which is only marginally better. Anyone who’s been in IT long enough can share stories of how oversized versions of TQM, CMM, P4, etc were mandated on their once nimble project to disastrous outcomes.

    So, is a healthy fear of “P” (and “B”) be justified? Perhaps not, but I put it to you that P&B are tools, like knives or fire or electricity, only more difficult to use effectively. Nobody fears these things intrinsically, but the stakes are high, so one needs to seriously consider the capabilities, experience, dedication, diligence, and motives of the folks wielding them.

    • vareynolds says:

      Dave, thanks for commenting! Yes, I agree with your take on the “B” word as well as the “P” word. I’m not a fan of the one-size-fits-all approach, either. And, you’re absolutely correct, finding that sweet spot is tough to do, but it IS doable. The last time I was able to deliver that sweet spot (I was the acting Project Manager), I will tell you this: the project came in on time to the originally scoped plan (not the 25th new ‘launch date’ that was put out there, but the original), it came in just under budget (we were able to save some money because we needed less rework than we had planned, er, padded for), and we delivered all of the features originally scoped as well as a few add-ons (because we had more available time for new features since we didn’t need that time for re-work). The senior management had subscribed to my approach, thus allowing me to implement the processes that I assessed that we needed and do away with those we didn’t. I also was empowered to monitor and to ensure the processes that we agreed to were followed, which is key (many places implement process, yet fail to have any oversight). It was the best project I had ever worked on in terms of scope, budget, goals attained, client satisfaction, and project team satisfaction.

      Love the “tools” analogy–it’s very true.

  7. vareynolds says:

    I also posted a link to this “P Word” post on the testing blogosphere in the Software Testing Club group on LinkedIn. I’ve copy-pasted a couple of replies with the author’s permission.

    Managers use Process as a stick. Engineers use Process as a shield.

    I had an excellent Manager who allowed me to push Process as a shield for Engineers to block bad Management decisions and drive improvement.

    Our industry does not have enough good Managers to properly use Process.

    • vareynolds says:

      Ben – Thanks for commenting! It sounds like the “processes” the organization had in place that your teams were following were not the right ones , else using them as a shield what not be needed. Can you give us an example of how you pushed process as a shield? Thanks!

      • vareynolds says:

        As always, these discussions fall into semantic issues. I need to clarify Process. Informal Process can be anything to anybody. It’s informal. Formal Process includes activities, techniques, tools, and measurement to consistently provide result.

        A morning routine includes several steps to get from bed to start the day. Many steps are taken. Some have sub-steps. Measurements provide information to identify optimal steps and order steps. Tools and techniques help compete the steps.

        Individuals and teams get processes from two sources: internal and external. Individuals readily accept internally generated processes. After all, these processes come from the individuals and usually effective. Externally sourced processes cause problems. Even small discrepancies from current activities become major stumbling blocks.

        Effective process start with understanding current activities, tools and techniques with appropriate measurements. Management needs to establish measurement policies to understand activities and not punish individuals. Individuals appreciate measurements that show performance. Measurements change to reflect changes in activities. Individuals take ownership of processes and measurements.

        For example, measuring hot water usage in the morning routine would not help optimize starting the day. Hot water usage helps being Green, but that’s not this focus. Time for each activity and overlap between activities identify opportunities to improve the process. Imposing someone’s morning process would, generally, be poor. It’s unacceptable for someone to collect and analyze the data to give me improvements. I need to understand collection and analysis to select from various improvements.

        Process fails when imposed. After some resistance, people might begin to understand and accept the change when it can be clearly communicated. Any suspicion of secondary motives significantly impede acceptance.

        Process can be a shield from poor management decisions by starting with current activities most developers do or accept doing. Once Developers document their current process with activities, tools, techniques and measurements, Management is left with 3 alternatives: follow the process, allow Developers to improve the process or ignore the process. The first 2 options put Developers in control. They execute an optimal process, while Management tracks the results. The last option puts poor outcomes on the broad shoulders of management. They sign off on violating the optimal process and have to answer for failure. They are less able to pass the failure onto Developers.

        A well defined process provides Developers with clearly defined activities, techniques, tools and measurements. Measurements are critical to prevent Management arbitrarily dropping activities and blame Developers for failures.

        • vareynolds says:

          [In response to other comments that are posted on the Software Testing Club's group discussion of this blog post on LinkedIn]

          Reading these comments seem to invalidate the premise of this topic. People do not run away form Process. Everybody has processes through out their lives. Some processes have rule of laws and commandments. Just try to violate Configuration Management processes, Oh, the screams you will hear when the next build fails. Try to skip the copyright heading. Legal will be on your butt in no time.

          So, what is the actual point in the topic? It’s formal VS informal and internal VS external processes. We don’t run away from informal processes because we are allowed to adopt parts and reject the rest. We don’t run away from internal process that we develop for ourselves. We run away from external processes imposed on us.

          This means “process guys” mess up by trying to impose process.

          We need to document existing processes from teams with appropriate refinements to ensure consistency, repeatability and measurements. Staff need to understand and accept our documented process. Refinements need to be fully explained for Staff to understand and accept benefits. Measurements are most difficult for Staff to accept. Managers try to use measurements to punish individuals and teams. Before we let Managers access to new measurements, we should present results to Staff for them to connect with their activities and ensure measurement actually matches the activities

          Fully defined internal processes are difficult for Managers to corrupt. Staff won’t turn tail and run. These processes come from the Staff and are owned by the Staff, not Management. Staff use process to prevent Management from asking for unacceptable risky activities.

          People don’t run away from Process. They run away from poor Managers with “process guys” who try to impose processes.

  8. Nice Blog with Excellent information

  9. vareynolds says:

    I also posted a link to this “P Word” post on the testing blogoshere in the Software Testing Club group on LinkedIn. Please check out the many additional comments here: Many people chimed in, writing long diatribes that are very interesting. I encourage you to check it out, too!

    I’ve copy-pasted a couple of replies with the author’s permission.


    Some of us don’t run. Some of us attack.

    …Well, maybe that’s a strong word. But I think you are mis-using the word “process”, as most people do. This abuse of the word by people who (consciously or unconsciously) wish to dominate and control other people is a major reason for its bad reputation.

    Another major reason is that relatively few people are nerds who read about cognitive artifacts (see Things That Make Us Smart, by Don Norman) or Situated Action Theory (see Situated Action, by Barbara Suchman) or about making tacit knowledge explicit (the field of ethnometholodogy).

    Process does NOT mean procedure. If it did, then we could not talk about how things happen that do not “follow procedures.” For instance, if you talk about the process of, say, a plant growing from a seed, what you would be talking about is how things happen. You would be making a causal explanation, but not specifying a procedure. A farmer might follow a procedure, but that procedure tells us nothing about the process of how a plant actually grows.

    People who are serious about understanding cognitive work must appreciate the huge role of tacit knowledge and skill which will not and mostly CANNOT be expressed in terms of defined procedures. Whenever I hear a “process” guy tell me that I have no process, I reply “since I am able to do this thing, I must have a process. It’s apparently not a process that you understand, but please, don’t conflate process with explicitly specified procedure.”

    It is meaningful to say that you “follow a process” if you have a description of a process and try to make that process happen. But if you didn’t follow a process, and still accomplished a goal, then that means, by definition, that there must have been a process by which that happened.

    I find it useful to use these terms:

    - Process: how things actually happen
    - Practice: what people actually do
    - Method/Procedure/Tool: what people attempt to use to get things done
    - Defined Process: A normative story about how things happen

    • vareynolds says:

      James – Thanks for commenting! Good food for thought. You bring up good, interesting points for debate and discussion.

      Tacit knowledge. Yes, it can be difficult to properly convey or communicate this knowledge to others through written or even verbal communication (or procedures). But it’s not impossible. That’s how we have the assembly line in the automobile industry. And the list goes on and on.

      I also like the example you tell of a “process guy” who states that you have no process. I find that guy humorous because I think that there’s a process for everything, whether it’s formal or informal, documented or not, repeatable or not. As you stated, if you didn’t follow a (pre)defined process, but achieved a goal, in retrospect, there was a process that was followed. But it was either unknown or not communicated prior to implementing the process. But there was a process nonetheless.

      Putting procedures on paper, for some reason, “formalizes” a perceived process. And that scares people. Yet, at the same time, many people desire order. Order and organization are driven by refining steps taken to achieve a goal or complete a task to make the steps efficient. Once efficient, then further refinement is taken to make the steps repeatable. Everyone does this in his or her daily routine, let alone in a work environment. By having a procedure, I’m able to shower every morning when I’m half-asleep—I’ve already honed my steps and the order in which I do them to make them efficient and repeatable, thus creating a procedure. I haven’t formally written these steps down, but I do follow these every day in relatively the same way (that was a little Dr. Suessian with the rhyming. I couldn’t help it.). I also allow wiggle room in the procedure for some slight changes, depending on the situation (to condition or not to condition? That is the question.). Alternate paths, if you will. At the end of the shower, I’ve reached my goal: I’m clean. And I followed a process that consisted of a procedure that was flexible enough to give me the right amount of direction to reach my goal without being so constricting that I was unable to alter the process, the procedure, or the steps based on my tacit knowledge as the situation required.

      My main viewpoint on the word “process”—as it pertains to overall application management and delivery, not just testing—is that it need not be heavy-handed, painstakingly detailed, or involve reams of documentation, or, as you stated, to control and dominate other people (I’m picturing Cylons now…). I think that as long as the people involved with the process agree on the definition of what that process is, then, well, it’s a process. Plain and simple. Now, do I think that just because we’ve said that something is a process means that it’s a GOOD process…? Well, that’s the start of an entirely new conversation… ☺

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>