Project Planning & Execution

One of the most common issues I have noticed with Project Management and companies approaches is they focus, almost entirely, on only one out of the two core disciplines of Project Management. To me, a Project Manager has two key high level tasks. Planning the project and executing the project.

These things are distinct, indeed, a properly written plan (along with all the supporting information you'd expect like estimates, PIDs and anything else the organization requires to initiate a project) should be of sufficient caliber that any other project manager can pick it up, and with a modest ramp-up, execute the project.

Execution is the project delivery, it is of a great deal of importance and naturally, every Project Manager does it, the issue is with the understanding of the PM role, the support and expectations from the company and the tools available. I will deal with each of these in turn, but first, what is execution?

Execution is the effective management of tasks to reach the agreed goal. A properly planned project is broken down into core tasks. The level of detail of the tasks is determined by both the nature of the PM and the nature of the project. Execution may also be termed delivery. In a large project, responsibility may be delegated down to team leads for the execution for some of the work packages, but the accountability should always remain with the Project Manager.

Company Expectations:

Companies expect a Project Manager to plan and deliver, but they rarely really think about the skill of delivery. Recruitment is very much focused on experience with planning and estimation, most of the focus from the business is how well a project can be planned for presentation to the client. From there, the PM is often left alone. Tools and processes are in place to support the project, up to the point where the project really initiates.

Naturally PM's are judged on the project delivery, but the dichotomy of providing planning tools, sign-off processes and ensuring wide buy in for pre-project work as compared to the far greater free reign given for execution is seldom addressed.


The issue here is MS Project. I, like most Project Managers, have something of a love/hate relationship with MS Project. On the one hand its an invaluable tool for any project and it’s the pre-eminent project planner out there. (Comparisons with things like Merlin, Omniplan, OpenProj or other suites is a post for another day) but sufficed to say, like most Office applications, whether it’s the best there is or not, it’s the one 95% of the world will turn to.

As a planning tool, it works effectively, though eccentrically. As an execution tool, it is extremely limited. Whilst you can enter progress into a task, and use baselines to manage changes to delivery dates it is extremely clunky. It’s a feature that’s not really designed for, and one that does not cope well with delivery priority changing. Amending a tasks order can break the plan completely necessitating hours of painful reworking to make the deadlines match. A particular frustration in a Agile delivery environment, or even one where you have that rare creature, a client with inconsistent priorities.

Execution is about effective task management. I have, with more than a little success, used ticketing and issue management tools like Jira to fill the gaps. Jira in particular is excellent, as it has a 'symbiotic' plugin called Greenhopper (now Jira Agile) specifically designed for delivery Scrum or Agile projects. I find that doing the required project plan, and then taking those tasks in to Jira Agile and turning them into issues, or even better testable user stories is an effective way of managing execution side of Project Management. Each ticket isa discrete piece of functionality or work, the User Story within the ticket allows the developer and QA to understand what has to be completed for the functionality to be complete and the Jira Agile section of Jira gives the project manager low effort mechanisms to measure velocity (story points need enabling as they are not available by default) and to track via swim-lanes the status of various pieces of work. Additionally the Agile tab allows for easy, drag and drop prioritization of User Stories.

I've also always had a soft spot for post its and whiteboards.(find me a old hand at Agile that doesn't!) Tools needn't mean digital. Whiteboards are obvious and easy. You can gather around them and work directly. They only really fall over when you have co-located teams. I'd always suggested, before spending money on tools that require a process change, get the basics right with post it notes on the walls.

In the end, the key take away is to ensure that you provide the Project Management Office with the tools to both plan and deliver a project. Both of these elements are key for a project manager and for a smooth delivery.