The 3 P’s concept needs no introduction just like “Snow White and the 7 dwarfs”. But, I would like to put the 3 Ps in perspective of software development and delivery.

Let’s start with the last P (no means less significant as this is the last one of the 3, that’s why I want to start there to avoid any confusion), Product. This is the bread and butter for everyone involved in software development. Product here sets the goal, expectation, deliverable, measures the success of the effort, and is the end result. This is what we all work towards.

Process is about how a defined set of procedures are needed to run the operations, way of doing things, how to control the outcome of efforts, standards, and modus operandi. People is about who carries out the processes, works towards building the product, and contributes in a way no creature other than people (yes, I do like the Terminator series, but this is software development, not watching a movie!) can do that makes or breaks the product.

These two P’s, People and Process, depending on the maturity and the nature of the business (I know… there are several other factors that play in here, I am trying to keep it simple to make my point!), one of these is given the status of poster child and the other is treated as evil necessity. Organizations that are bigger and operations-heavy are more process oriented and mostly the people are mere actors. I could understand this as when you are big, you can’t be at the mercy of one good employee that can crash the whole system, and so they dilute the value of the people part of it by substituting with high doses of process. Start-ups and emerging businesses rely more on the people quotient and somewhat downplay the process side of things because in a past-faced world processes are perceived as stumbling blocks. And, there is some truth to that too!

In my opinion, whoever came up with the 3 P’s they got it right, it holds good in any organizational setup. The organization just needs to find the right balance of People and Process. The examples are abundant when an organization leans towards one of the 2 P’s sacrificing the other and facing disastrous future (if there is one!).

Let’s take software development scenario and explore how things play out in organizations that have imbalance of these 2 P’s.
Heavy on People, lighter on Process:
•    The same guy(s) will be doing everything, becoming a bottleneck.
•    Egos come in the way of organizational goals.
•    Watch out for “Cowboy” coding till the last minute, and you will see plenty of “on the fly” processes in the name of perfectionism.
•    A process is what’s done today. (You could always use being nimble as an excuse!)

Heavy on Process, lighter on People:
•    Get caught up in the process hysteria. Process does everything, we just need button pushers.
•    Process becomes synonymous to bureaucracy, but we deny it.
•    We speak in SLAs, and meeting the SLA is treated as an accomplishment, not exceeding the expectations.
•    As the business needs change, we find ourselves telling people that we can’t do that as the process won’t allow it.

No Process is complete without active and sincere participation of people, and no Peoples’ undertaking is complete without adequate processes. Actually I would like to call the 2 P’s People and Process as one ‘BIG P’. People and Process are inseparable; it only makes sense to call them as one big P. I give you an example of a software delivery situation where this is manifested. You can identify similar scenarios where People and Processes go hand in hand, and the success of the Product is dependent on how synchronized these 2 P’s are.

Your organization incorporates a Continuous Integration policy (an Extreme Programming paradigm) to accomplish smoother production deployment efforts. There are several tools that can be used for Continuous Integration efforts such as Make, Ant, Maven, Cruise Control, etc. depending on the framework and platform. All the developers are encouraged to check into a source code repository on a frequent basis (Extreme Programming prescribes on a daily basis), the builds are automated, and every night the applications are built from the source control system. Emails are sent to an escalation group if the builds fail during the nightly process. The deployments are automated.

Now, this is a good process to put in place. But, without people this won’t yield the results that the process is put in the first place for. It only helps you to make sure that the builds are built successfully without compiler errors, and the necessary libraries are linked up. That’s no indication of runtime success. If a configuration file is not packaged as part of the deployment, and never checked into the source code repository, or if the build is not tested in a clone of the production environment (most UAT environments are not true clones of production), that’s good enough to give you couple of surprises when you deploy to production. Every artifact that makes an application work in an environment must be checked in and be part of the deployment process, and this is something you can’t rely on a process alone, process only takes what’s submitted. It’s the people who help and make the process work.

I will stick with my overloaded definition of 3 P’s from now on; a BIG P with People and Process, and Product!

Tags: 3 P's, continuous integration, Extreme Programming, people, process, product, software deployment, synchronization of people and process

This entry was posted on Monday, June 23rd, 2008 at 11:12 am and is filed under IT Management, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. Responses are currently closed, but you can trackback from your own site.