Adding Value

My MacBook has a sticky note displayed in the corner at all times as a constant reminder of successes and failures.

"What we must decide is how we can add value and not how valuable we are"
- Edgar Z Freidenberg

These days so many Project Managers learn Microsoft Project, hound resources to complete tasks, record issues in Excel, take a test and voila!  Look how valuable I am!  I am a Project Manager!

Let's say I come to work for you. Obviously you think I can contribute to the success of your business, and I think I can contribute as well. But if on my first day I walk in and think, "they will never do this without me" will I set the expectations for failure?

How do I achieve any value with that statement? When I sit at my desk on Day 1, I have not yet achieved anything! I have only promised to achieve and add value. So I start about the business of adding value.

Ok, so let's say I walk in on Day 180. I have a couple wins under my belt. You call me first when you have a new project to discuss. Now am I valuable? You bet. But you cannot put my value in the bank, or declare it to shareholders. You can tell the shareholders that you are backing me for a big project because of my previous record of adding value, but the shareholders will still judge us both based on the end value added by our project.


I add value by delivering. I can achieve it best with transparency; if I know the business strategy. Perhaps our company needs entry into a particular market and profits are not key. Maybe we must conform to government regulations and exact requirements and costs are critical. We might even take a smaller project in hopes of getting more work at the client. I will plan the project so that the most critical elements will get the most attention. I will tailor my day-to-day management based on the overall goals and objectives of the project, not by blindly following a canned methodology.

I also add value by bringing information to you, so that you can make informed decisions. "Did you see the article that the government has extended the deadline for compliance?" "It looks like our competitor just got that big contract we were hoping to get." "Companies X, Y and Z just announced products in our market."

Companies exist to make profit. And management must produce that profit. Seems simple, but not all workers care about this. As a business owner, I care. I always look for cost cutting measures in projects that won't affect quality, and ways for utilising staff better.  

Perhaps Dr Freidenberg wanted us to keep achieving: Set expectations and never rest on our laurels. I can rest when I'm dead. Until then, I'll keep adding value.

Project Manager Time Quadrants

In 1995 I managed my first Information Technology project. It was for an organisation that did not have formal methodology experience, but they were pleased that I did.  It was very much a 1 to 1 relationship between me, Project Manager/ Business Analyst and the Project Sponsor/ Subject Matter Expert.  My focus was on capturing requirements and feeding them back to the developers, managed by another line manager. I spent nearly all of my time managing the relationship with the key stakeholder, and delivering the project; almost none managing the relationship with the delivery team and administering the project.

By contrast, in my last project, I had 15 high-profile stakeholders and subject matter experts. My delivery team was spread across 3 divisions with 3 different managers. I was considered one of the subject matter experts in the technology, and this organisation has a large and complex project reporting structure.

How is one project manager meant to fulfil all the roles in the Project Management life cycle?

Generally, there are two things a project manager spends time on: Relationship Management and Delivery Management.

Relationship Management focuses on who you spend your time with to get the results you have promised for the project. This can be Stakeholder-focused such as the Project Sponsor, Steering Committee or End users or on your project team who are providing the deliverables.

Delivery Management focuses on how much time you spend providing feedback on progress. Administrative focus is heavily-based on methods, formulas, EPMs and reports. Delivery focus is based on showing frequent and accurate results, such as prototypes and releases.


If we plot these on a grid it looks like this:

So let's say you spend 100% of your time updating Gantt charts, checking on task status, writing reports and updating budget spreadsheets. We call this the Project Administration Quadrant. More time is spent on reporting and communicating with the team.

The opposite extreme is the Stakeholder Manager Quadrant. The Project Sponsor or Owner has hired you, the Project Manager to turn a mish-mash of opinions into a functioning system, application or network.  This is the hardest of the roles because it requires up to 100% of your time setting and managing expectations of the stakeholders who want (or don't want) the project to succeed, whilst focusing on the delivery of their objectives. You have little time with the team, and little time to report on progress. If the Stakeholders are high-profile, a Project Director might be brought in to manage the individual project managers. This is the Project Manager role I prefer, but with a Project Director in place (or with me as the Project Director).

If your time is spent managing the delivery team and the deliverables, you fall into the Team Leader Quadrant.  These are usually straight forward requirements with a small number of stakeholders.


Lastly, the Program Management Quadrant requires a lot of administrative time and management of stakeholders. Program Managers rarely interact with the delivery teams or the act of delivery unless problems arise.

So in which Quadrant does your current project reside? In the next blog, I'll show you how to use this quadrant for your project planning.