Culture of Success: People vs. Process Paradigm (Post #9)

This is one of my favorite topics; the People vs. Process paradigm.  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:

People Dependence

  • Organization depends on its people to effectively execute work
  • Cons: can be mistakes, lack of accountability & not repeatable

Process Dependence

  • 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, 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 groups 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 project management group was viewed as a trusted area of 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.

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.guideline

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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s