Skip to main content

Author: Barry Currry

The Project Mindset – Fact or Fiction?

I have been thinking about this project management topic for many years. Is the Project Mindset real?

Is there a culture or a set of habits or behaviors that can define the Project Mindset? Do Project Managers have a Project Mindset?

What makes some people more suited to projects than others?

What are the traits to look for when selecting a team for a project that may not necessarily have direct project experience?

What can essential knowledge sharing do so that the team members are clear on the project culture?

This scenario is becoming more relevant as operational staff in many organizations are increasingly expected to work on projects as they have intimate knowledge of the business processes impacted. Although operational targets are similar – they tend to be repeated, so the team knows how to achieve and repeat them.

The Project

When we look at a project in general and key elements of a project, here are some of the ways in which a Project can differ from an operational environment.

  • A Project Has a Beginning. It is not a pre-existing entity.
  • A Project Has an End. Once the scope is delivered, the project will finish.
  • A Project is a Temporary State – it will not continue forever. Project teams, Rooms and Ways of Working are temporary.
  • A Project is Unique. Even if the delivery of a project is part of a wider program, the project is unique to its team, site, and installation. A project is not repeated.
  • A Project is Not Part of Business as Usual. Projects are not defined operational processes and tasks which are easily repeatable.

Project Resources

Looking at the above features. The First two items, i.e. the Project has a beginning, and the Project has an end is obvious to most people and needs no explanation or introduction.

The other three elements Temporary State, Unique and Not Part of Business as Usual create some of the biggest challenges for Operations or Support teams that are suddenly thrust into projects or find themselves on a project team.

Operations and Support teams are used to a routine. Each week looks and feels that same, standard work practices, standard tasks and a fixed meeting schedule for each week.

A Project pace of activity will vary as it moves from Kick off to Specification, Design to Build, Build to Test, Test to Qualification, Qualification to Implementation and Implementation to project close.

With each of these project phases comes a different challenge, a different pace and the ability of the project resources to adjust. The pace and change to the level and type of activity are critical to the success of the project. This change of routine, pace and activity are what most operations based people can tend to struggle with for the first time they are working on a project.

Project Culture

A Project Manager or Engineer with years of experience will instinctively know when to adopt a different pace within a project whereas the operations resources will just become comfortable with varying levels of pace and change.

When the pace changes some of the resources will adapt and deliver even if they are moving out of their comfort zone. Personally, I have always encouraged people to keep learning and to move out of their comfort zone from time to time as this experience will promote the individual growth.

As Project Managers and Project Leaders should we avoid or to address the aforementioned comfort zone? Is prevention better than cure? If a resource has no project experience, should we consider them for business-critical projects?

Alternatively, should we offer them advice, coaching, and support to facilitate the transition from a non-project to a project way of working? Are people capable of adopting the “Project Mindset?” This is an opportunity for you to develop as a leader by coaching someone into a position of confidence in their new role.

Team Selection

When selecting Operations based resources for projects consider the factors above. Is the person suited to a change of pace, change of activity, or change of routine? Directly asking the person may not yield the correct answer. You need to do a little research on the individuals as you would when recruiting for any role.

Find out if they have a track record of adopting change into their daily work. What has their past response to new company policies, procedures, processes, and systems? How have they responded to pressure situations in the past or to last-minute changes of direction?

You need to do your research when hiring project resources for several reasons, but above everything else the biggest constraint is time. As projects have a fixed planned duration, you may not have the time to take a risk on a resource.

In Summary

Moving from operations to project based work should be seen as an opportunity to grow as an individual and expand the capability of the person and the organization.

There no hard and fast rules to selecting project resources but I look for the “Project Mindset.” I define this as a set of characteristics that will provide an indication of how a person will respond to a project.

How I summarize this is:

  1. The ability to cope positively with change
  2. A willingness to dig deep to complete a milestone
  3. Does not tend to knee-jerk react to surprises encountered on a project
  4. The Capability to move roles and work multiple roles to get the job done
  5. The ability to switch off and chill after a period of high-intensity working
  6. Must not take any work-related discussions personally
  7. Can keep focused on the end goal
  8. Believe the end goal is possible
  9. Can support the team to deliver the scope at all costs

Sounds easy, yes? I would love to know your thoughts on this topic.

Rescuing a Troubled or Failing Project

Project Managers from time to time are called in to help rescue projects that are failing. Here are a few areas a Project Manager…

could focus on when determining the corrective action needed to bring a project back on track.

Background to the Problem

The first action is to understand why you have been called in to support or help rescue the project– what is the nature of the problem or problems? – Have the issues been defined? What was the trigger that caused the client to take action? How did the client recognize that there was a problem?

What is the project problem statement?

Understanding the background and current situation of the project allows the project manager to formulate a more effective corrective action plan to bring the project back on track. Some questions to ask are:

  • Has the issue been clearly understood?
  • What has lead the client to recognize that there are problems with the project?
  • How is it known that there are problems?
  • What evidence is available? Assume nothing here.

When did the issue first occur?

Understanding the timeline of when issues and problems occurred within the project can also assist in putting together a root cause of the issues and problems the project is facing.

When was the problem first recognized?

When did the project stake holders officially recognize that the project is failing and needed help? When posing this question, it is important to understand the difference between the symptom and the underlying cause. A symptom is the effect of the problem, and although related to the problem, the focus should remain on the reasons behind or the cause of the symptom.

The first symptom may have manifested itself sometime after the root cause event that triggered the symptom. Therefore – How did the problem first manifest itself? What evidence is available to substantiate the claims?

Looking at the key performance indicators of most projects – these include:

  • Schedule
  • Cost
  • Scope

Is the project late on a number of key milestones?

Is the project greatly over budget?

Has the scope of the project changed?

What controls are in place to monitor these KPIs? When were they first flagged and by whom and why?

Understand Key Process Indicators or Project Health Indicators that are used on the project. It is helpful to understand how these indicators are calculated, how frequently they are reported, and the history of indicator results over a period of time.

Previous Action Taken

Previous attempts at taking corrective action should also be fully understood. Ideally, you don’t want to try to take a corrective action that had previously failed. You can also learn as to why corrective actions failed so that that corrective actions that you put in place don’t fail. Some questions to consider:

  • What action has been taken so far?
  • What has been done by whom and when in the initial stage of the investigation into the failing project? This needs to be understood because early action without research or careful thought I have made the issue worse.
  • Has someone recorded what he or she have done and recorded the impact of what he or she have done?

Problem Impact

An another critical component of understanding the project’s current situation is to understand the extent of the project and how the project’s failure to meet expectations is impacting the business. Project failure has a cost to the business and understanding that cost can assist in creating a meaningful response to bring the project back on track. Some questions to consider:

  • What is the impact of the project problems to the business?
  • Where should the project be now in terms of progress?

Additionally, understanding the extent to which the project is off course. In order to make corrective actions, understanding of the projects current deviation from plan is important to understand. Some questions to consider:

  • Where is the project now in terms of percentage complete?
  • Is there are metric available on Earned Value against Planned Value? Are these figures reliable?

Review the Original Objectives and Scope

Before taking corrective actions on a troubled project, a project manager should understand the project’s scope and deliverables. The project charter outlines the scope and deliverables for the project as a starting point, but changes most often have occurred in the scope. Project scope and deliverables might no longer be valid because of changes in the business. Some questions to consider:

  • Are the original Objectives and Scope of the project still valid?
  • Have the objectives and goals of the project changed?
  • Has the scope changed enough to significantly derail the project?

Review the Project Performance to Date in Detail –

List all of the key deliverables, milestones and assess:

  • Where should they be in terms of completion / delivery?
  • Where are they (status)actually in terms of completion / delivery?

Assessment of the original plan against current status in detail is critical, and there is no shortcut to completing this assessment. The assessment will \will take time, and the devil is in the details. There can be a huge number of deliverables in a large project, so this process is not for the faint-hearted.

It is recommended to be as binary (yes or no and complete or not complete answers) as possible during this review so that the results are honest. It is important to note that you will not make any friends during this process so try to take the emotion out of discussions by focussing on the facts. Some clients may hire in external resources with no personal history on the site in order to get to the facts and remove the possibility of any personal influence.

If a task is late or has had to be repeated has this resulted in an increased cost? Is this substantial? How is this being measured on an hourly/daily basis?

The resulting report from this review process will arm you with the factual data from which you can get to the root cause of the problem(s) and re-plan the project to get back on track for a successful outcome.

Project Risks

Review the original project risks to assess if they are still valid. Have the project risks been updated? Are there any new risks that need to be assessed? How will they affect the project? Have any of the original or new risks been realized? Have they had any impact on the project delivery?

Analyze the Data

Are there any patterns emerging from the review data. Using these results – look for patterns such as consistent issues with departments, people, vendors – that are consistently late or repeating tasks not completed correctly.

If there is an obvious pattern with a delivery and this is identified back to a person or a department, look for further evidence. Is the person experienced enough? Are they the right person for the job? Is there role in the project clear to them and everyone else? Are they doing other work that is preventing them from focusing on project work? Are they capable of the work assigned to them? How was this person or department originally assessed for capability? How was individual performance being monitored?

Are there other factors influencing delivery -e.g. personal behaviors, interdependent service inefficiencies, process issues, system issues, late equipment/software material delivery, procurement issues?

Are operations based resources being allocated enough time to work on the project? Has the client prioritized the project to reflect the required delivery times?

The purpose of this analysis should not be a witch hunt but an honest review of the data recorded in order to get to the real issues.

Do not overlook here to review the controls processes if they fail to capture an issue early enough to control the issue.

Report

Produce a report of your work that should include but not be limited to:

  • Background to the Problem
  • Findings
  • Results
  • Conclusion
  • Recommendations

Utilizing the data that you have collected and the conclusions that you have drawn, based on evidence -communicate the results and recommendations to your main point of contact at the client site on a 1:1 basis.

Present the raw facts to them on confidence and seek their advice on:

  • What would they prefer to do next?
  • How should this information be released to the wider audience?

This will be a good measure of the politics on site and how it should be managed. Remember this is the client’s choice on how they wish to manage the situation.

Although it is rare -it is not unknown for clients not to do anything following such an investigation as corporately the “right thing to do” would step on too many toes and may not be the politically correct course of action.

Take Corrective Action

In order to get the project back on track you will need to do the following based on what you have learned:

  • Define the Scope
  • Perform a Project Risk Assessment
  • Re-plan the activities with new milestones
  • Re-work the budget to reflect the new plan
  • Select the project team (typically some original -some new members)
  • Create a proposal outlining the Project be delivered and what will be different his time in order to prevent a recurrence of issues.
  • Make this presentation to the key stakeholders and seek support and approval to move forward.
  • Kick off the project and implement the necessary controls.