Posted by: kerrywills | September 26, 2014

Dealing with difficult people

Every place I have worked at has their share of “difficult” people. These are people who seem to enjoy making everyone else around them miserable. They yell, they berate others, and they look to find fault in everything.  To top it all off, somehow they even move up the management chain and get into positions of power.

I have found several techniques to work with difficult people.

1. Maintain composure – The worst thing that a PM can do is to react to a situation, which will empower the difficult person even more. Stay calm

2. Learn what sets them off – Hopefully there are others who can advise on triggers, otherwise it becomes a (painful) learning process. Identifying these triggers will allow you to tailor your approach to be conscious of them

3. Focus on the facts – People have a hard time debating the facts and this way the conversation focuses on that versus the people themselves

4. Play to their egos – While this sort of condones their behavior, playing to their egos is usually a good way to gain their support

Not sure what other techniques people have but please share them. As long as we have to work with people, there will always be difficult people and we will have to deal with them.

Posted by: kerrywills | September 19, 2014

Project Management is Issue Management

In my opinion and experience, projects are successful due to two main factors (1) Diligence in planning and (2) Rapid issue closure. For this article, I will ignore diligent planning and assume that all projects plan properly with the right assumptions, estimates, plan, etc (I know, I know, but bear with me).

With a good plan in place the key to successful execution then becomes all around how quickly issues are identified, raised and closed.  An issue can be with resources, stakeholders, code, logistics, or anything else that affects the project. Even the slightest issue can have implications on the project  – for example, not booking a conference room for a meeting may delay a critical meeting where decisions are needed and now the team’s productivity slows. I will touch on the main areas of Issue Management below.

Issue Identification – It is imperative that the Project Manager has a good pulse on the team and the operations of the project so that issues get identified early. Techniques such as Earned Value, status meetings, Management by Walking Around, and stand-up meetings are intended to facilitate information from the project to note risk areas and issues early.  PMs should be conscious that identifying issues is a critical part of their jobs – because usually they spend a significant amount of their time on issue closure which just perpetuates the loop (see my soccer article).

Issue Escalation –  A good issue escalation path must be in place for the project. This means that team members need to understand who they should raise something to and when they should raise it. PMs should have a culture of honesty, quick identification of issues and a focus on resolution (vs blame). People who get ‘punished’ for raising issues will not do that again, and by the time the issues are known they are much bigger.

Issue Closure/Prevention – Once issues are identified they need to be aggressively managed and closed. In my opinion, this is the primary job of the Project Manager during the course of the project. With the plan in place the PM should be looking at anything that could cause a delay to that plan and look to eliminate that as early as possible to keep the team moving. The PM should also consider ways of making sure that that same type of issue doesn’t happen again.

Issue Management is about early identification which relies on a clear escalation path and rapid closure. If a Project Manager can stay on top of the issues and help the team to resolve them, then there is a greater chance of project success.

Posted by: kerrywills | September 12, 2014

Planning fom Left to Right

With most projects, we get handed a date that we have to work towards and told to make it work. I call this managing from “right to left” which means we start with the chronological end dates (on the right side of the gantt) and try to work backwards. This works sometimes as once in a while we get lucky and are able to make it work. But because complexity and size of programs has grown exponentially, it is more likely that this method of planning doesn’t work and inevitably results in one of two outcomes…

1. The date gets met but because of rushing, quality suffers and there is a lot of fallout

2. The team gets to a point where it is not possible to meet the schedule and scope winds up pushing out

I believe that realistic plans go from “left to right” and are based on practical start dates combined with effort/duration which then predict the end dates.


The key is to make this fact-based planning with such facts as deliverable start dates, duration, and dependencies. Then when these get laid out a PM can demonstrate the critical path and schedule milestones which demonstrate a realistic/credible plan. It also helps because if there are delays, this model can then show the updated dates. This approach does require leadership courage to push back but I think it is better to have hard conversations early on around a realistic plan than to get into a problem and have to have harder conversations later (and, BTW, you will still wind up delivering in the same timeframe that was originally planned).

Posted by: kerrywills | September 5, 2014

How deep to go?

As I have moved up in my PM career I have always struggled with how deep to get into my programs. I am now running portfolios of programs which have dozens of projects and organizations under them. On one hand a Portfolio or Program should be structured in such a way that there is cascading accountability to Project Managers and Team Leads. On the other hand, I think it is important to understand enough of the details to manage effectively.



Take, for example, the picture above. This is a classic Program with multiple Projects and Application Areas under it. In the classic model, the Team Leads are well versed in their areas and the PMs knowledge spans the projects but only goes so deep into the areas (as noted by the brackets only going half way down the App row). Then the Program Manager also knows the Program information and some of the project information.

This model is very hard to scale when you have large programs. My current portfolio/program has five sub-programs and roughly 45 projects under it so it is hard to get to lower levels of detail for all of those projects. I do find, as projects have issues, those are the ones that tend to require going deeper in them.

I am sure that there are other models so I am interested in feedback in “how deep to go?”

Posted by: kerrywills | August 29, 2014

The 5 Sources of Truth

Over the last twenty years I have used many tools to manage my work and programs and have evolved to the point where I only use five documents to manage my programs. I treat these as ‘living’ documents that are always up on my computer and constantly being updated…

  • Scope/Release – This is the master view of all scope items in the program aligned to projects and release dates
  • Critical Path – This is my program-level view of milestones and tracking towards them. This is informed by a more detailed plan
  • Financial – The aggregate view of financials (actuals and forecast) by project and cost type
  • Issues/Risks – My running list of worry items, risks and issues with the audit trail of progress and specific actions with dates to close
  • Notes – I process all e-mails and documents through OneNote which allows me to organize all program information in one place
The 5 Pillars of Managing Program Info

The 5 Pillars of Managing Program Info

I find that by using these five items I always have everything that I need in front of me as opposed to trying to hunt down meeting minutes, documents or content. Obviously there are many documents that support these but I find this the most efficient way to manage program information. I know that every PM has a different style so I am curious what tools others use to manage their programs.

Older Posts »



Get every new post delivered to your Inbox.

Join 65 other followers