Following on from the article outlining my five Project Action Principles, this article expands upon the first Principle:
Consciously and deliberately focus on achieving outcomes over executing activities. Outcomes deliver projects, but not all activities result in outcomes. And move as quickly as the situation allows.
Also see “Additional Resources” at the end of this article for detailed strategies and techniques.
A delivered project is an accumulation of outcomes
The ‘achievement of outcomes’ is what projects are all about. Why do we need to state the obvious?
The answer is that most projects are structured around tasks or activities, not around outcomes. Even if outcomes are addressed through the definition of deliverables (also called “Products” in Prince2), the rest of the project will commonly be defined in terms of people doing work over a period of time.
A project delivers value through outcomes expressed as deliverables. These deliverables are produced by accumulating the results of many smaller “project outcomes” at every level of the project over its lifetime.
A project outcome is an event, result, or consequence of actions by project team members that move the project towards its goal.
Project outcomes result from interaction of groups and individuals on project activities, for example:
- An executive makes a decision based on team recommendations
- A person or group completes a task
- A software or hardware component is delivered to a team that needs it
- Multiple people reach an agreement
- Two teams integrate their two components together
- An accepting manager signs off a deliverable
Although the list above seems quite straightforward, it isn’t always the case in reality.
You’ve probably experienced many interactions in a project environment that don’t lead to outcomes. An “outcome-less interaction” is any activity which does not produce a result.
You may have sat in a meeting where nothing really happens; the project manager is the only person speaking and repeating many things from the previous meeting; there is a lot of discussion, no decision reached, and/or are no notes captured and distributed; or a regular formalised process (e.g. reviewing actions or issues) produces no meaningful progress.
Do you sit in these meetings seeing the same items coming up week after week?
In a highly-constrained work environment such as a project, these types of events do not only waste resources, but they generate a feeling of “lack of purpose” in the project; as a result, it eats away at the morale and quietly promotes sub-optimal behaviour.
Most project managers focus their attention on the work that is to be done and the tasks that need to be performed.
The problem is that it’s easy to generate work in a project environment. Almost every schedule is written in terms of tasks that will be performed by certain resources over specific periods of time.
Work can be generated from almost anywhere: a process definition in a corporate or “branded” methodology; a template document (e.g. a Work Breakdown Structure); or a person’s job title or perceived role in the organisation (e.g. a Solution Architect who sees their job to write a Solution Architecture Document). But this work aren’t outcomes that can contribute to the overall outcome of the project.
As a project manager, I use outcomes to define work, not the other way around. For example, what I really need is the best solution architecture for the project constraints and ongoing support of that architecture (e.g. to deal with questions or issues arising from technical teams or vendors). The outcome I need is the architecture; hence, the vehicle for that architecture could be provided in many different ways, and each team should select the optimum deliverable structure.
Bringing an outcome focus to your project
Firstly, as a project manager you must recognise that this principle is your first and foremost responsibility. A project manager must prepare and condition themselves to facilitate an outcome-achieving environment. This posture must be constantly maintained and woven into every interaction that occurs in the project.
There is no such thing as a casual interaction in the life of a project manager. No matter how casual it may appear, each interaction needs to be planned and setup to result in an outcome. Everything you say, do or imply communicates significance to the project team and broader participants.
Secondly, a project manager has to develop his or her skills in recognising work-based or outcome-less interactions, which usually have some justification to the project team or its broader stakeholders. In micro-techniques article, I will explain, help identify and give methods for handling outcome-based work, protracted work, pointless work and orthogonal work.
There’s not much more satisfying to a good project manager than a precise, crisp and well-thought out interaction which results in an outcome, with little friction or waste.
Doing this rapidly: Outcome velocity
Just as important as outcome achievement, the velocity of outcome achievement must be considered. As a general rule, shorter projects are more successful than longer ones, all things being equal.“There is no greater, but unacknowledged, risk to project delivery than the duration of project execution.” – Adam Russell
In the “Models” section of this blog, you will find a model called “The Gradient of Terror”, which explains the above statement.
A project must ramp up its operational tempo to drive outcome accumulation as quickly as attainable. This acceleration to full operational pace must start from Day 1 because the impact of delays at the start of the project can ripple down through the rest of the schedule. The result is often with great negative consequence: a week lost at the beginning of a project is most likely going to have a bigger impact at the end.
This principle does not mean rushing people to make decisions, or not taking the appropriate amount of time to assess and deliberate on decisions. It means taking no more than the necessary amount of time that is suitable to your project goals.
Adopting the principle of “Driving Outcomes, Rapidly” could be the most fundamental and pervasive change that you can bring to bear in your project, regardless of the methodology or action plan that you are using.
The role of the project manager is not to push or bully people into outcomes. Their role is to provide an environment where outcomes can be achieved more rapidly and facilitate outcomes when the opportunity arises.
This requires constant focus, specialised skills, commitment and courage; but it has the biggest impact on project execution and can be used to drive and enable the implementation of all other project management principles.
If you think this will take up a lot of your time, you are probably correct. But if you look at this from the perspective that it is your primary accountability as a project manager, then the time will be well spent.
Fortunately there are countless number of tools and techniques to support this approach; the below resources will help you work out the best ones for your project.