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.

Posted by: kerrywills | August 22, 2014

The Evolution of “Reply to All”

Well as is always the case every six months, we had the classic “reply to all” evolution this week at work. It happened in the same way that it always happens and followed the predictable evolution path…

1. Person sends message to entire company (in this case 40,000 people)

2. Other people think they were on the wrong distribution list and ask to be removed by replying to all

3. Then people tell other people not to reply to all by replying to all

4. Then some people realize this and send recalls to all people


In this case it actually sent millions of messages and brought down our mail servers for several hours. Now, I can’t figure out which is worse, the person who selected every single distribution list or the people replying to all on purpose. And not sure why ten people had to say not to do it, thus contributing to the problem. One day people will learn about BCC which is the cure to the reply to all problem.

Older Posts »



Get every new post delivered to your Inbox.

Join 63 other followers