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

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:

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

Culture of Success & Ongoing Team Dynamics (Post #8)

The project is kicked off.  Work is in progress.  Results are being seen.  Everything is Awesome!!  Until it’s not.

As the project leader, you want to be the first stop for team members when issues and conflict arise.  This will require you to have a higher level of EQ (emotional quotient, or intelligence) than the average, the ability to resolve conflict quickly, and celebrate the wins when milestones are met or the project completes.  These are never easy tasks.

Interacting with the Team.  I want my team to feel comfortable interacting with me at any time.  To do that requires building trust.  I have found trust doesn’t come until after the project starts.  Once resources are assigned, the kick-off usually happens almost immediately after.  Getting time with individual team members comes once work is in progress.  There are 5 areas which I focus on when interacting with my team:

  1. Be Open & Approachable: No one likes a grumpy PM.  Even if you’re having a bad day, keep it inside when a team member comes to you.  If you’re not approachable, they may quit coming with issues or concerns.
  2. Be Present: Team members can’t talk to you of you’re not around.  I’m in meetings literally 6-7 hours a day, but I always find time to swing by and talk to my team.  I frequently have remote workers, so will ping them via instant messenger or email just saying hello and check in.
  3. Be Consistent: This really focuses on EQ.  I don’t ever want a team member to ask themselves “What’s he going to be like today?”  Try to handle situations the similarly every time.
  4. Deliver on Commitments: When I commit to do something for a team member, that commitment becomes my priority and I intend to deliver ASAP.  I keep them updated on progress if I can’t deliver right away.
  5. Be a Gatekeeper from Distractions, Without Being One Yourself: Don’t be afraid to pull out the “Scope Stick” and beat away stakeholders who come in asking your team members for different things.  Keep the office politics away if you can.  I’m also a recovering control freak who has lapses.  I do my best not to get into the weeds of someone’s work unless I absolutely have to.

Conflict.  Conflict is what I like to call a “Growth Industry” in that it never goes away and you can always get better at handling it.  Conflict comes in all shapes and sizes, but I’ve boiled it down to two categories; Professional and Personal Conflict.

Professional Conflict: Have you ever seen two Enterprise Architects try to agree on how a new major system should be setup?  Or an Architect and Designer agree on a new building concept?  Those conversations can get pretty heated and you’ll get some elevated voices.  But look at the intent; they both want what’s best for the project and feel their approach is better.  This is Professional Conflict, and it’s actually one that I don’t mind having!

Most often, resolution comes with having an adult conversation.  Listen to both sides and try to understand their points.  Sometimes they want the same thing but say it different.  Other times they can agree on an approach.  If needed, bring in a third party expert who can help render a decision.  There are times where it’s not a win-win situation for the conflicting parties and that’s OK; your job is to deliver the best results for the project.

Personal Conflict:  Let me run down a real conversation I once had with two employees (names are changed to protect the innocent, and guilty) who were working in a co-located area:

  • Me: Tell me what’s going on.
  • Dan: This whole team is stupid.  Everyone.  I have to do all their damn work because they’re incompetent.
  • Emily: If you’d just let us do our jobs instead of checking out our code, making updates, and checking it back in we’d be further along.
  • Dan: I do that because I know if you did it, everything would be wrong.  Like I said; stupid.
  • Emily: You don’t have to be so mean to us all the time either!
  • Me: Dan, have you seen issues with the rest of the team’s work?
  • Dan: No, but I know they’ll screw up.
  • Me: You just answered my question. [excuse Emily from the room].  Check in your code, pack up your shit and move back to your area.  I’ll let your manager know you’re off this project and get someone else in to replace you.
  • Dan: You’ll fail!
  • Me: I think we’ll be fine, maybe even better.

Personal conflict comes from a team member, or members, not like others “just because.”  They can’t justify it.  This needs to be killed immediately, including removing a team member.  Personal conflict can destroy morale.  As for Dan, he ended up leaving the company soon after I removed him and the team flourished with his departure.

Celebrate!  I can’t stress celebrating enough.  It doesn’t have to be much, just showing recognition to those who have done the work.  On many

Yes, I made this!

projects, I tell the team once we hit a milestone, I’ll bake a cake and use my 2nd grade level

art skills to put something on it.  Here is an example.  I’ve also had happy hours and lunches to celebrate, as well as invite the sponsor and/or key stakeholders when possible.  This also brings the team together and strengthens relationships among the members.

This concludes Team Dynamics.  Next, I’ll go into the People vs. Process paradigm.

Culture of Success & Team Dynamics: The Kick-off & Defining Your “Rules” (Post #7)

You’ve painstakingly identified project roles, tools, filled in the gaps, assigned the team, and now it’s GO time!  Before any work starts, there are two things that must happen first; the team kick-off and defining my rules as the PM.

The Team Kick-off.  A well planned kick-off meeting sets the tone for a successful project.  This is your chance to energize the team and an opportunity to show your competence as a leader to guide them through the project. The PM will also discuss how the project aligns with strategic direction. Here are some points to help make a kick-off successful:

  • Bring food
  • Clearly articulate the goals of the project, what done looks like, and the project’s alignment to overall corporate strategy
  • Define what’s in scope and just as importantly, what’s out
  • If possible, have the project sponsor and/or key stakeholder attend to reinforce the project’s criticality
  • Define roles & responsibilities of the project team
  • Go over the team’s communication plan, including recurring cadence & medium (especially for those remote teams), who facilities & who takes notes, and document repository
  • Talk about the project management process and ask for feedback
  • If known; key milestone dates
  • Define your “Rules”

Your Rules.  I got this idea from a mentor a number of years ago.  As a PM, you will have information and issues thrown at you from all directions and it can be difficult to keep it all under control.  To that end, establish your “Rules” and ask your team members to follow them as best they can.  These are setup so your team can work well with you and keeps things flow.  Below are my rules; feel free to create your own:

  1. I don’t like long emails and rarely read them.  Keep emails short with bullet points and expected results.
  2. “Rule of 3”: After 3 group emails pick up the phone.  Email 4 should be a summary of what was discussed and agreed to.
  3. If you think it’s an issue, bring it to my attention ASAP.  Don’t let me be surprised later.
  4. If there is an issue bring me possible solutions, your recommendation and why.
  5. If you allow work outside of the change control process or make promises to stakeholders, I reserve the right to lose my cool.
  6. I make your issue my priority.

The final installment of Team Dynamics will cover ongoing interaction with team members, conflict, and celebrating!

Culture of Success & Team Dynamics: Building the Team Before Building the Team (Post #6)

The project team; those individuals you need to work together to accomplish a goal.  You’ll be working with them a lot; leading, handling issues, giving direction, managing conflict, and the list goes on.  But before all that, you need to know not only WHO will be on the team, but just as importantly (if not more), what ROLES are required.

Identify the Roles First, Not the People.  Have you ever started a project and heard “You need Johnny for this” or “Make sure Cindy is on your team because she’s great!”?  Chances are you have.  Instead of identifying people, identify the roles you’ll need first.

This is a lesson I learned running a large IT project years ago.  Once the project was approved, we pulled the people we thought were needed and got to work.  The issues we found right away; people have “day jobs” plus other projects, some of the roles we thought we needed we actually didn’t, and we quickly found out we didn’t have some key skill sets required and had to look for contractors.  Needless to say, it was a rough start.

Instead, create a list of roles you’ll need, the tools (whether it’s licenses, applications, equipment, etc), when they will be needed and how long they will be engaged on the project.  By identifying roles, you see what you need and whether or not you have them.  Sure, you probably have some people in mind, but at least all the roles and tools are ID’d.

Fill in the Gaps.  Once you have roles and tools identified, it’s now time to fill in the gaps.  This is often difficult because with gaps come costs.  Consultants or staff augmentation may be contracted, software purchased, or licenses subscribed to.  There is also the option to adjust scope to reduce, or provide current staff additional training.  Ultimately, however, you’ll need to fill in these gaps.

Assign Your Team.  You’ve identified the roles, filled in the gaps, and now it’s time to build the team.  Most often, you get people assigned from their managers.  The problem is, managers don’t always assign the right people to the project.  Sure, they may have the technical knowledge to complete tasks, but they may also be on other projects, constantly in operational fire-fighting mode, or may be the person that’s difficult to work with and the manager just wants them out of their hair for awhile.  If you have any say, try to get team members who are not only competent in their area, but also able to work well with others.

Determine Your Process.  Lastly, determine your project management process.  Some companies have established processes.  Others leave it up to the project manager.  So, determine if waterfall, agile, or “Agi-Fall” works for your project.  In the next phase of team development, ask the team for their input into the process to create a greater sense of ownership.

Next up, the team kick-off and your “Rules” as the PM.