After focusing on “Project Inefficiencies – or how to improve project management by improving leadership” in my first article, I would now like to take a look on how to successfully plan a project.
I am personally very fond of thorough planning – and I like to plan ahead. I strongly believe that project planning is a big part of (successful) project management in IT, especially when one is responsible for large projects on a global scale. The theory behind it is indeed quite simple: To generate a project plan, the project manager starts with defining the project scope, selecting the appropriate methods for completing the project (for example waterfall or agile), then listing the tasks necessary to complete the work and grouping them into a work breakdown structure, estimating the work (= tasks) and from there deriving the amount of resources required, staffing the project and end with defining the project organization with roles and responsibilities.
Once established and agreed to by all necessary stakeholders, the project plan (including schedule and organization) becomes what is known as the baseline schedule. Progress will be measured against the baseline schedule throughout the life of the planned project.
Theoretically, project planning is therefore a well-defined process. But even with an increase of “certified” project managers, I have only rarely experienced best practice when it comes to planning processes and projects. And often, bad planning leads to project failure, and therefore to unnecessary costs.
I would like to share the main 5 challenges I believe you can encounter when working as a project manager in IT:
- Often, a project plan is a power point slide with a bar chart and individual bars representing tasks or groups of tasks. A line is drawn which presents a timeline, indicating where the project should stand. But as no further details are gathered, the status on the timeline is more of an indication based on impressions instead of facts.
- Sometimes there is no overall project plan, just toll gates which are tracked with KPIs. The tasks necessary to complete the project are not known, neither is the time which is necessary to deliver. Therefore, the status of the project in between toll gates is also more of an indication based on guess work, rather than a status based on something measurable.
- Many times the project scope is not defined, there is no detailed project plan and development simply starts in an agile manner with the execution of sprints. The expectation – or rather hope – behind this approach is that the execution of the sprints will lead to a satisfying result, matching the expectations which were never articulated in the project plan. Surprisingly, this is very often not the case.
- In other cases, the project scope and plan are known, but effort estimations are not done based on scopes or tasks. Without effort estimations, the project staffing is done based on a vague “feeling” of how many people could be necessary to complete the tasks at hand. Often the amount of available resources is then not sufficient to complete the tasks in the given timeline, raising questions about the competence of the leader/project manager.
- Many big organisations create an organisational structure as a first step, when planning, defining and setting up a new project. They define who is responsible for which “box” without defining and understanding the scope of the “box”. Afterwards every owner of a “box” needs to define his/her roles and responsibilities and tasks within the project.
So what can a project manager do to handle these challenges?
- Project planning is more than just defining a masterplan on a slide or defining an org-chart. The project masterplan is the result of a thorough planning process which starts with defining and understanding the project scope, defining the approach and methodology (agile, waterfall or a mixture of both), listing of all tasks, provide effort estimations of the tasks, defining a high level plan, calculate how many resources are required in the given timeline, staffing the project, define the organisation, adjust timeline and create detail planning.
- Then further planning is required regardless of the chosen implementation methodology. (Somehow there's still the notion that agile projects do not require a thorough planning process…)
- I believe that the opposite is necessary: The more agile a project, the more effort needs to be spent during the execution to review and adjust planning. On the other side, with a project based on waterfall, planning needs (usually) a bit less adjustment.
I strongly believe that a good project plan and therefore a thorough planning process is a crucial base for a successful project in IT. Saving time by rushing through this phase – or not asking all the questions necessary – will pay back with hectic times once the project is up and running. Every project manager should invest the necessary time to go through the process in order to avoid unpleasant surprises – or questions about your competence as a leader – later on.