This is one of my favorite topics; the People vs. Process paradigm. This is a debate I see carried out in LinkedIn groups and PMI meetings on a frequent basis.
When companies are small with few employees, processes are thin and it relies on people to get the job done. As it grows, the dependency needs to shift and have more processes in place. Let’s define each:
- Organization depends on its people to effectively execute work
- Cons: can be mistakes, lack of accountability & not repeatable
- Organization depends on processes to ensure proper execution of tasks
- Cons: Can be too bureaucratic, paperwork heavy, someone (hopefully not YOU) needs to manage
The question is, is one better than the other? Or, what is the right blend of people dependence and process dependence?
There is no “One Size Fits All” Solution. If you’re creating a process or enhancing an existing, there is no magic bullet for success. Every company, culture, project and team will be different. No matter what you hear, read or are told, there’s no one size fits all. Though PMI offers a good framework, each company should tailor their methodology.
I’ve started a couple of project management offices (PMO) in my career. The first was for a small company that had little process and wanted more structure. We assessed their needs and slowly implemented processes based on the biggest challenges. It took a couple years, but eventually the PMO was viewed as a trusted department in the company. It was a tailored approach that worked well and is still in place today.
The second was for a slightly larger company that again had very few processes. A PMO was stood up right away and a director from a Big 3 consulting firm was hired to run it. He had a playbook with lots of processes and artifacts. He was smart and driven to implement the playbook, but the step we missed was assessing what change the organization could handle. Six months after starting the director was let go and PMO disassembled. A couple of processes remained, but for the most part, groups resorted back to what they knew.
When working with companies on either new or existing processes, there are a few artifacts I require; project charter, schedule (see next section for the level of detail), risks/issues log, and populating status reports. These standard artifacts define done, highlight problems that can pop up, and keep stakeholders informed on progress. I also require regular meetings with teams and stakeholders. Above those, all other processes are open for discussion.
Define Rules vs. Guidelines. When creating processes, I don’t want them to be too rigid or bureaucratic. This can decrease buy-in by project managers and they’ll work to skirt around the system. Instead, I have created rules and guidelines.
An example is a project schedule. I require every project have a schedule, which is a rule. The guideline comes from the level of detail the PM will track to. If it’s a complex project, there may be more detail. If it’s less complex, there may be just key dates. The PM is allowed the flexibility to get as detailed as they see fit.
What Came First; the Process or the Tool? Let me start by saying a tool will NOT help you unless it supports and/or enhances and existing process. I see questions on LinkedIn asking what tool people like the best. My response is “it depends!” Look at tool selection as a project in itself, with a sponsor, requirements, vendor RFP’s and deployment plan. Understand if the tool can start small and be scaled up as employees grow accustomed to using it.
In the final installment of Culture of Success, I’ll touch on virtual team management.