Breaking News: Team Members are Humans.

Introduction

I’ve recently attended an instance of a virtual training course on interviewing job candidates. While the course and trainer were great – make no mistake here! – there was one thing that made go ballistic.

While portaying the benefits of the specific interviewing approach, about 5 slides in, the “Utilization Rate” was named as one of the most important metrics of a successful hire.

Come again?!

I’ve then asked what “Utilization Rate” meant and it was exactly as I feared:
The amount a hired person was being busy on a given project.

Utilization is good for machines

Coming from regular business education I know that a lot of traditional management practice revolves around making sure resources are used to their maximum efficiency.

After all if you pay a resource for time you may as well make sure you’re getting the most output in that time.

This works well on the factory floor. With machines.

If you are renting, let’s say, a assembly robot, for a rate of 1000$/day flat you better make sure that robot is assembling like hell distributing the fixed cost over more pieces produced.

This theory worked well there so why not transfer it into the office?

People are not machines

The difference with people is that people are not machines.

People are not steady in their output, not do they perform the same under 50% workload as they do under 90% workload.

If you look at the concept of “Slack time” this describes that when doing time management you should always have more than 20% of buffer available for dealing with interruptions, unplanned work or plain socializaton.

People with near 100% utilization are very rigid in their schedule and unable to cope with rapidly changing requirements. They also become robot-like having zero time for their colleagues, which actually hinders them in getting things done, as the informal (social) networks are oftentimes the key differentiator between someone who could and someone who can.

Looking at other literature, for example “Focus” by Daniel Goleman, a key factor in creative, breakthrough thinking is the ability to be able to control the flow of your work including time with no specific commitments.

Furthermore  – looking into all the learning and community initiatives – all of those make you  more connected, knowledgeable and ultimately a happier person. When should you do all this if you are near 100% utilized? In your off-hours?

Keeping skills and networks active and cultivated makes sure that people that are effective today will STAY effective tomorrow.

Truth be told – going for high utilization will give you better results in the short term. But with our rapidly changing world constant investment must be made in education and personal development.

With near 100% utilization there is no time to make that happen. In the long term this will mean that any “resource” will become less effective and fast.

Trust

Why even care for utilization?

I believe it comes from the thinking that a manager has to know that everyone is busy. But why would that be necessary?

Looks like classical Theory X thinking:

editor_image_e4ab0861-d2b5-4159-875f-f176763c6a5d.png

Image stolen from: https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y

If you assume your workforce is made up by Theory X people you have to assume people will try to trick you as soon as an opportunity presents itself. That would require a lot of command & control because you cannot trust a Theory X person.

 Fortunately no human being is a Theory X person.

All human beings are Theory Y people, striving for purpose in life, trying to get enjoyment and fulfilment in what they do.

Don’t believe me? Read “Drive” from Dan Pink or “Start with Why” by Simon Sinek.

So how come some people act like Theory X? It’s mainly because their environment drives them to do so. Because they are incentivized to act like Theory X.

Think about it. If the environment assumes you are a Theory X and you are evaluated and measured by utilization, what would you do?

You would do what gives you the most benefit in the given environment – thus you make sure you are looking as utilized as possible.

If you are a motivated worker you may even do a great job DESPITE of the environment (or try to change the environment, but that’s a different story).

Getting to Y

Looking at the things that exemplify a Theory Y person it looks like this is the person you would want to work with.

So how do you get there? Easy. It’s all about trust.

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done. ”

– Principles behind the Agile Manifesto (http://www.agilemanifesto.org/principles.html)

Trust is central to Agility.

You have so many talented people in your teams. People with rich experiences, a large inventory of education and perhaps even a healthy amount of humor.

How come you trust these people to arrive at work every day, navigating 66% of the rest of their life on their own, but as soon as they have entered the office floor you treat them like unreliable, greedy, selfish idiots that need constant supervision?

You already have the team you need to get the job done.

Trust in their ability to solve the issues in your project. Give them the freedom to act without having to come to you for approvals constantly.

Establish an understanding of and and agreement on the goals and why they are worth achieving and the rest will come  naturally.

Measure by Results

In the end it does not matter that everybody was very busy on your project. It does not matter that you can show that all of your resources were 98% utilized.

The only thing that matters is what the project can deliver and if the results are what the client & business need.

That is why in Agile we have empowered teams that focus on goal attainment while the manager steps back. That is why we focus on servant leadership to ENABLE all of the workforce to do the best they can.

  • Establish goals that are worth attaining.
  • Explain the why and listen for questions and new perspectives you might have missed.
  • Create a shared understanding and agreement of the road ahead.
  • Get the heck out of the way.
  • Be available and open to answer questions on the way and help out if someone is in trouble.
  • Trust your team to get the job done, because they will.

People are not things. Don’t treat them like things.

On Project Success – Why Traditional KPIs are not enough

Schism

Something is amiss in Project Management Land and it’s not the usual “Traditional PM vs. Agile PM” squabble. It’s a lot more fundamental as it goes to the core of every project:

The measure of success.

This is different from the question of goal attainment, a topic which in my opinion has been examined from a lot of different angles and can be measured to a satisfactory degree, from the very basic following the SMART / INVEST criteria to fully-fledged project scorecards. No – this is not about goal attainment, it’s about finding out if we’re are targeting the correct goal in the first place.

“A major cause of the disconnect between completion and success of strategic projects is that most PMOs still rely on the same old metrics as a proxy for success:
Operational measures such as on-time and on-budget, and stakeholder satisfaction.”
– Matt McWha, CEB IT Quarterly Q3 2014

 

“We’re all familiar with the phrase “what gets measured gets done,” but what if we’re measuring the wrong things?”

– Andrew Horne, The IT Scorecard Disconnect, How Metrics Can Derail Your Strategy

Could it be that over the years we have become utterly efficient at checking for goal attainment and lost contact to WHY we’re actually pursuing  these goals?

The Curse of Tradition

Looking at traditional project what’s getting measured? We usually check if:

  • We were within or below budget
  • Met the project dates & milestones
  • Met the quality requirements

Tick the checkbox next to each of these requirements and the project is golden and we can move on to the next task. If only it were that simple.

Traditional KPIs usually miss one central aspect: Short and long term contribution of the project to business success.

Not true you say? Well tell me – when does a project end? Does it end when the delivery is complete? When the customer has paid?

What about long-term effects such as market share? Reputation? Or even more down-to-earth things as ongoing maintenance / support costs?

All of these effects contribute to a business’ success but very few projects are monitored beyond the hand-off to the customer – and even if they are it’s usually with the wrong metrics or the wrong intentions.

100 PMs were asked about project success…
70% cannot adequately quantify project success
38% report overly positive results to secure future funding
80% analyze / review completed projects inadequately (*)
(*) Due to focus on classic KPIs such as delivery date, cost, quality metrics – not on business results
– John Ward. „Delivering value from IS and IT investments“, Cranfield School of Management, 2006

Long-Term Effects

All of these issues create the problem of a business closing off projects one-by-one but ultimately stumbling towards doom.

What we need is not blindly following a plan but an examination of long-term effects on the business. This requires new KPIs such as:

  • Project Fit with Customer’s Needs at Time of Delivery
    Delivery is not about what the customer wanted twelve months ago but is needed now.
    On average 33% of all requirements change within 12 months. Was the project able to keep up?
  • Effect on Business Reputation
    Did the business reputation bloom or suffer during the project?
    What are the long-term implications on the brand?
  • Development of Turnover Time and Cost for Change Requests
    How fast was the project team able to integrate change requests?
    What was the cost associated with each change?
    What is the trend of the turnover time and cost?
    Did the project team get more efficient over time?
  • Team Knowledge Accumulated and Shared
    What new skills have been brought into the team?
    What is the level of existing skills?
    Has knowledge been transferred between individual team members?
    What new ideas and developments have started as a side-effect to the project?
    What is the long-term implication on the business’ ability to deliver?
  • Ratio of Participation in Innovative Development
    What’s the ratio of projects targeting an innovative market compared to those targeting a saturated market?
    Is the business just treading the ground it already knows or is it pursuing new endeavors?
  • Level of Project Sponsor Engagement
    How did the executive sponsor’s engagement develop during and after the project?
    Where they engaged? Did it seem that they recognize the project’s importance or were they mostly just walking piggy-banks?
    Do the projects align with the corporate vision? (Usually goes hand-in-hand with high sponsor engagement)
  • Market & Mind Share Gained
    What was the effect on the market share of the business? Will it be able to look back on an expanded market share?
    Perhaps by winning over return customers and creating positive word-of-mouth/references?
    Did the new product capture new market share? How did the market share develop over three, six or twelve months?
  • Long-Term Project ROI
    Was the project actually worth the investment?
    This is not just adding up costs and comparing with project income – it’s also about measuring the impact on future business.
    Did the project drive the customer away or did it actually increase the prospects of new contracts?
    Who said that the project will only pay out once?

Agile Performance Measurement

The Problem of Measurement

As more and more projects shift to the Agile methodology more focus is put on the entire team’s performance and delivery. This in turn means it does no longer matter if you as an individual have completed all your assigned tasks if the team as a whole has failed to succeed. While the approach of “we’re in this together” is definitely a large step forward when delivering value and results it becomes problematic when managers are required to do individual performance assessments of each team member.

While I do not have the perfect solution I want to give some insight in my personal experiences and opinions on this topic.

There is no Team in I

The main problem with the situation is that Agile promotes “one team” thinking which is tremendously beneficial to the performance and success of a project. On the other hand high-performers want – and to some degree – deserve to be recognized for outstanding work. The issue of if and how to reward individuals in a team environment is a tough cookie on it’s own that I’ll skip in this context.

What I do want to emphasize is that in an Agile environment the individual rating of team members is made even tougher as you technically need to separate the contributions to the team result. Also the question comes up: “If I emphasize team results and team achievements, what do I set up as hard, measurable success criteria in the Performance Assessment?”.

For both questions there is no ideal, one-size-fits-all, silver-bullet solution. But there is perhaps a way to be both Agile and be able to recognize performance fairly.

Hard Facts for Everyone

When it comes to hard, measurable business results I would always recommend to do this on a team level. This means goals like release dates, quality metrics, X amount of leads converted into contracts, etc. should always be defined for the entire team. These global goals then go into each team members’ Performance Assessment goals. The important part is that everyone on the team has to have the same shared goals. It’s not okay to cherry-pick or let team members choose their own selection.

If you cannot define goals that can be applied to the entire team then it might be worth investigating why people with widely differing goals are put together as a “team”.

It might be preferable to openly discuss and define these goals in the entire team so that everyone can contribute. In the end it’s important that every team member can commit to the shared goals and be evaluated by them.

Using this technique you can enforce the “one team” spirit while at the same time laying hard ground rules for evaluation.

Going Soft

It’s pretty obvious that successful project work is a lot more than just following a set of defined, measurable goals. It’s also HOW the team approaches new challenges, works together and gets the value delivered.

This touches upon areas such as problem solving skills, inter-personal communication, knowledge-sharing and the general work values. As these things are less easy to define and may differ from the assigned/perceived role of a team member things will get difficult at this point. I would recommend splitting Soft Skills into two groups: General team rules and individual expectation.

The general team rules should encompass how the team approaches a given situation, it’s work ethic and conduct. This includes things like “We will share knowledge” or “We will identify the root cause instead of treating the symptoms”.

If you have defined the general team values when initially creating the team AND WRITTEN THEM DOWN – good job! If not it now would be a good time to have the team define these general values and write them down (e.g. as a poster on the wall) so it is clear HOW the team accomplishes it’s goals and goes about the daily work. You should make it clear that the team will be evaluated on each individuals follow-through on these rules.

It’s important to note that these rules should be a guideline and that it is okay and normal if people are not always 100% or even 80% on track – we’re still humans not machines.

For role-based expectations, e.g. if you have a team lead, architect or someone with a special role on the team you should define the expectations as you would with every personal goal – direct and in private.
As it is clear that these expectations are tied to the individual and the individual’s role this approach does not conflict with the general team rules and you can draw the line more clearly.

Matching Expectations with Reality

When it comes to comparing the expectations with actual results the approach largely depends on what you are evaluating. The hard, measurable team goals can be checked during sprint review and delivery gates. The approach will be more or less the same as with every other business goal. For the “Soft” values and skills things get very different very fast.

Any kind of evaluation of the softer goals requires experiencing how the team acts. This means attendance at the regular team events such as Scrum Meetings and Sprint Reviews is pretty much required. How will you evaluate somebody if you haven’t seem them in action? But by all means do NOT visit the meetings taking notes on each members performance! It’s more about getting a feeling where the strengths and weaknesses are. If you are not directly involved in the project because you are “just” the line manager make sure that you regularly check in with the project manager / product owner involved. Also make sure that the PM/PO understands what criteria you are evaluating team members on so you can get meaningful feedback and not just a general “performance was pretty okay”.

Another tool at your disposal are 360° reviews. These kind of reviews take in feedback from peers, managers, people-managed and the person in question to form a better picture of the performance. If you want to do this make sure you understand how the review process works as it is quite different from the regular manager-evaluates-employee approach and also be open about your intention to use it.

In the end you should be able to combine business results with feedback on the individual’s “softer” values to create an accurate evaluation without counteracting Agile’s spirit of teamwork.

The Model

ape