Erkki Koivusalo
Nov 2, 2015

Essentials of Project Management

The aim of this article is to describe project management in a nutshell. Additionally it explores virtues of traditional and agile ways of running projects. This summary is based on my own experience on the topic, aiming to briefly cover key topics discussed wider in PMBOK guide and related literature about agile methods, using the terminology and overall structure of Project Model of the IT Standard for Business.

This diagram outlines a typical project landscape:

EssentialsofProjectManagement_1

In the context of this article the term “customer” means an organization being the customer for the project. The starting point of any project is a need or opportunity identified by a customer. To satisfy the need or capture the opportunity, the customer needs a solution.  From the perspective of the project, the customer is represented by various stakeholders:

  • Opportunity Owner who either identifies and/or promotes the need. Opportunity owner consequently initiates a Project Proposal to get the project launched and need satisfied. Opportunity owner might be a Business or Process owner.  Business Owner needs the outcome of the project in order to achieve his/her business goals.
  • Management who is in charge of authorizing the project and granting it the needed budget. The main concern of the management is to maximize the benefit of any investment versus its costs. Management is represented by the Portfolio Steering and Project Steering Groups. While Portfolio Steering decides whether the project will be executed the Project Steering gives guidance for the execution. These groups interact with the project at least via well-defined milestone gate reviews.
  • Project Owner who is accountable of the project outcome and provides ongoing steering and support for the project team.
  • End Users who are persons that eventually interact with what the project delivers. End users want to be able to perform their job as smoothly and easily as possible.

Apart from the customer there are also other stakeholders who may impact the outcome of the project, by delivering parts of the outcome, imposing restrictions and limitations or somehow changing the environment of the project:

  • Vendors who are assigned to the project in order to deliver components, systems or solutions
  • Regulators or standards bodies who may impose limitations by legislation, commonly adopted standards etc.
  • Competitors who might introduce some disruptions on the marketplace, impacting the originally identified need or the competitiveness of the planned solution

In this landscape the basic elements of project management are the following:

EssentialsofProjectManagement_2

Before starting the Project Execution phase, the Project Initiation Phase – as authorized by Management – is done over two stages: Concepting and Planning.

The need or opportunity has to be analyzed in order to describe it formally. The analysis is done in the Concepting stage by a business representative – possibly helped by a dedicated requirement elicitation specialist or the Project Manager. The result of the analysis may consist of documents like the Business Case, Financial Plan and ultimately the Requirements Baseline defining the expected solution (1). The format of the baseline can be a plain text document, a set of numbered requirements, use cases or equivalent which possibly can be maintained in a requirement database. The collection of requirements may also be called as a backlog especially for agile projects prepared to revise the project scope on ongoing basis. While for traditionally run projects the requirement baseline defines the agreed scope of the project, when going agile the backlog lists the known requirements in priority order and is subject to change in regular intervals during the project.

To get the approval for the project execution phase the Project Manager has to plan the project during the Planning stage. The key elements of the Project Planare as these:

The Project Manager has to define a process suitable for the specific case according to which the project will be run (2). In some cases this might just mean picking one of the options known as waterfall, incremental or agile development. In other cases it might mean more detailed way of working, for instance the specific ways how to involve stakeholders such as end users to the project work, in order to ensure a successful roll-out phase for deploying the solution.

From the requirements baselined and the process chosen the Project Manager has to derive the Work Breakdown Structure (WBS) for the project (3). WBS aims to list all the activities and tasks needed to (i) produce the solution and (ii) validate that it satisfies the need of the customer. When using agile methods the abstraction level of WBS – if created at all – is much higher than when using more traditional project management methods. This is due to the fact that with agile approach, planning in task level is typically done by the project team in short 2-4 week sprints using a rolling planning and estimation approach.

Based on negotiations run with the customer and the various contributors to the project, the Project Manager is able to outline the project schedule (4). The schedule is typically documented as a Gantt chart showing various activities of the WBS against a timeline. The Project Manager creates the schedule based on assumptions made for the resources available for project execution and any external dependencies as well. The resources cover both the staff (5) doing the work and any tools (6) needed, such as computers and software packages or applications. The estimated cost shall be derived by the Project Manager from the resources and time needed for the project. Again, when using an agile approach the schedule is there to show the planning targets or the time boxes agreed rather than a commitment in respect to project scope which an agile team will only provide sprint by sprint while gradually evolving the solution.

When the project and its plan – including project budget – are formally approved by management and the project gets authorized by the Project Portfolio Steering Group, the Execution Phase is ready to start. The contracts with external contributors have to be finalized (7) and signed to get the work started according to the plan. Soon thereafter the Project Manager usually organizes a formalkickoff for the contributors where the goals of the project and the project plan will be introduced to the project team.

The Project Manager is responsible for keeping the project on track with respect to the agreed targets i.e. delivering the agreed scope and quality of the solution without exceeding the allocated time and cost. For routinely run projects this might be straightforward but the more new and earlier unexplored aspects or unplanned changes the project will have, the more difficult this will be. Project schedule and cost overruns are typical for any industry where the project aims to create something else than a standard solution tried out earlier already many times. Traditional project management aims to achieve the agreed targets with very rigorous planning and risk management approach, together with various contingencies in budget and schedule to cover the unknowns. The approach for agile is somehow different: while the cost, time and expected quality might be frozen when starting the project, the scope won’t. Instead the project might have a scope target but the actual scope will only be revealed while the project team delivers features incrementally as picked from the backlog in priority order and the project finally consuming all the time and budget allocated to the project.

While the project is running the Project Manager has to monitor the progressand do corrective actions whenever needed to get the project back on track. There is a feedback loop (8) between the project execution and its management. In order to make the feedback loop effective suitable measurements have to be chosen and the cycle time of the feedback loop has to be kept short enough. Thus project work involves a continuous process of learning and adaptation. While for traditional projects this might mean the project manager doing re-planning or reallocating tasks, in agile projects the corrective actions mean removing obstacles found or re-negotiating contents agreed for current sprint.

To help the Project Manager to focus on the most important aspects to monitor, the project plan shall cover a list of risks identified (9). The risks have to be scoped with the probability of the risk occurring as well as the estimated impact if the risk will take place. At least for the worst of these risks counteractions have to be known and available in advance, in order to avoid the risks or minimize their impacts. In regular basis the list must be updated and the project status assessed against the risks identified, to ensure any potential problems would be solved sooner rather than later.

Managing the changes to the requirements (10) is essential for all projects apart from the simplest ones. The changes may come from various sources such as competition disrupting the markets, regulators introducing new rules to be obeyed, customer learning something new or simply changing the mind. The Project Manager shall take any changes agreed to the requirements into account for the project plan and execution. Such changes which impact the agreed key targets need approval from the management authorized the project. Traditional projects use a formal change management approach where approved changes to requirement will cause corresponding changes to project plan. In agile projects the new or changed requirements, if manageable within the given project authorization, are simply entered to the correct position of the backlog and the project team will start working on them when those requirements reach the top of the backlog.

Project Manager shall set up proper ways to communicate the project status to various stakeholders like Business Owner and Management. The communication covers project reports delivered on regular basis (11) but there has to be also an agreed escalation path for communicating such anomalies or issues which impact the agreed targets in a way which the project cannot internally cope with (12).

After the solution has been designed, developed and validated the Deployment Phase starts. Typically the solution is piloted with a selected subset of End Users. In the Piloting Stage end users start using the solution. Feedback is collected and analyzed to ensure that the solution will meet the business case targets and that both the solution and organization are ready for the rollout. When using traditional project methods these stages within Project Execution and Piloting are only done once in the end of the whole project or at the end of each increment. When using agile methods and DevOps these stages could take place several times during the project – in the end of each sprint – so that new features are implemented and validated in small steps throughout project. This helps the project to get feedback early on and change the course of the project on time, if the planned solution is not found appropriate by the End Users or other stakeholders. However the drawback is the constant distractions the End Users might experience by the project team involving them with the frequent mini-pilots. Finally in the full scaleRollout Stage the solution is taken into full production use.

Even a good Project Manager is not always able to complete the project with the originally agreed scope, schedule or cost – especially when there is considerable market pressure for contributors to bid optimistically to win the deal. This dilemma can be addressed by careful initial planning with sufficient contingencies or using rolling planning approach so that only the most crucial targets will be frozen at project kickoff. The solid project management practices should be used to ensure that while plans do not always come true, the customer will in the end get a solution which satisfies the most important needs, captures the key opportunities and keeps customer’s business going.

Contact us IT for Business as PDF

 

Looking for answers to your questions about IT Standard? Get in touch.