Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Seduction by metrics

MetricsIt is quite common nowadays to make decisions based on metrics. More and more PMOs and management are tasked to identify key performance indicators (KPIs) that reflect elements a business wants to measure. Decision making is based on what is being measured. This has definite positive sides – measurement is clear, decision making logic is consistent, there is early visibility if projects are derailed.

Yet, metrics do not always give you the entire picture. It is very good in stating the actual, but does not indicate what should be measured. The same metric can have different meanings. Consider this … two projects are running 15% under budget. However, one may be a fixed price project where this is a great outcome. You can earn 15% more revenue by deploying those resources elsewhere. The other may be a time and materials project, and suddenly you are faced with a 15% reduction in revenue and need to close another opportunity at a shorter notice that you may not have been anticipating. This is however something you can improve over time, as long as the metrics are scrutinised regularly.

Where metrics fall considerably short is in the human domain. In industries where intellectual property is key (i.e., information technology, design etc.), employee motivation is a key driver of success. Metrics cannot adequately capture if the workforce is getting tired and motivation is running low. No doubt some proxies can be used – contracted hours vs actual, defect correction rate etc. However, those can be misleading too. Staff may be putting in more time because they’re intrigued with bleeding edge technology, or correction rate could be high because requirements were poor rather than motivation being low.

Most metrics also do not cater for the difference in capability. For example, a great software developer can be up to 10 times more productive than a good developer, while commanding nowhere near the same difference in salary.  Most metrics are developed with a normal distribution in mind, as that is the only way you can calculate something repeatedly. That also leads us to devote more time into trying to improve those that fall below the normal distribution, rather than foster those that can make a real difference – the top performers.

So am I suggesting we should bin metrics altogether? Absolutely not. However, we must recognise what a metric can tell us and what it cannot. If we are relying on it to know conclusively if we are doing something wrong, then only time it can tell us so is after the fact, when the horse has long bolted. Metrics still do not excuse managers to get lazy and go into auto pilot. If we have an inkling we’re going in the wrong direction, and our metrics aren’t necessarily showing so, we still need to be able to make decisions and justify our reasons. Power of observation is still valid today as it ever was.

Agile is bad!

Not always. We have a tendency to solve problems we face with a single silver bullet. In the recent past, I observed an organisation trumpet it’s move to agile in multiple communications. This organisation had undoubted issues with delivering to commitments it had signed up for, and agile was seen as the way to fix all its ills. Yet, when I talk to those working in the organisation, they see little change. And surprisingly, the outcomes are no different now than before.


So is agile to blame for this? Or was waterfall methods (if indeed it was what they used) really to blame for their past failures. The reality is agile is not something that simply works. A cultural shift is required within the organisation to derive benefits from using any agile methodology. Without that, (so called) agile is just as bad as any other way of running projects. So what are the things that defeat agile in organisations?

Multi-disciplinary teams: Agile project teams must include subject matter experts from areas that they are delivering too. If a software is being written for automating taxes for accountants, then you must have accountants and tax specialists in your project team, along with your developers, testers etc. Technical staff cannot be experts, and this is why you will need subject matter experts. If experts get tasked with duties on top of their day job rather than dedicated time on the project, agile is bad for this organisation.

Decision autonomy: You get over the first hurdle and have the skills in the team that you need. Time comes to make the first choice between implementation options and your subject matter expert needs to get it approved by their manager, who is not available for rest of the week. If your subject matter expert cannot make decisions on the project with authority, agile is bad for for this organisation.

Urgency: A key tenet of agile is the delivery of working product at the end of each iteration. Iterations are intentionally kept short so prioritisation always focuses on highest value items, builds value incrementally, and avoids the bells and whistle distractions. If the organisation cannot get you decisions in a timely fashion, then you can be guaranteed to either twiddle your thumbs for parts of iterations, or pull too many moving parts into it. Either way, agile is bad for this organisation.

Change control: It is all well and good for the project team to work in an agile environment. What happens to the working product delivered by the team? Is the organisation geered towards receiving these products at such intervals? Can they cope technically? Is there enough staff to make it happen? Can the required training be produced in time? If the answer to these questions is no, then agile is bad for this organisation.

Procurement and audit: Agile planning is done in stages. Closer you are to working on an item, more detailed planning you undertake. In the course of the project, it may become clearer that delivering more in one area is of higher value than delivering on another that had initially been identified as a requirement. If the subject matter experts make this call and the organisation’s procurement or audit team later lambasts them for non compliance, agile is bad for this organisation.

The intent here is not to highlight deficiencies of agile methods. In fact to the contrary. Agile done well can be immensely valuable for organisations and an innovative and satisfying environment to work in. The key is to recognise agile requires a cultural shift in the way an organisation operates to make it truly worthwhile. You do not make agile project teams, you make agile organisations.

What motivates the New Zealand IT Professional?

I have just recently completed my Executive MBA. The final piece of the puzzle was a research project of my choice. I had always been interested in what motivates those in my industry. A great many also helped me by responding to the study, and therefore this is my attempt to thank them by sharing my findings.

Get the PDF summary here.

A massive ocean of literature exists on the topic of motivation. It can sometimes be a hindrance rather than assistance for IT management professionals. Some studies claim IT professionals are unique in their attitude to motivation and job satisfaction. With move towards a knowledge economy, understanding of these factors will play crucial role in future success of organizations. In addition, a shortage of skilled professionals may contribute to unique motivators in New Zealand. This research therefore aims to answer what motivates the New Zealand IT professional.

Herzberg’s Motivation Hygiene Theory
Contrary to previous assumption, Herzberg contends job satisfaction (motivation) and dissatisfaction (hygiene) were distinct in their contributors rather than two ends of the same scale. Resolving something that makes one dissatisfied does not provide job satisfaction. It merely reduces dissatisfaction. This is the theoretical basis of the study.

A modified model of Herzberg’s Motivation Hygiene theory by Smerek and Peterson was used for this study. A self completion questionnaire was distributed online through SurveyMonkey to a population of IT professionals accessed via a LinkedIn group. Partial least squared, a structural equation modelling based technique was used as the primary method to understand relationship between the various dimensions of job satisfaction, impact of personal and job characteristics, and turnover intent. Follow up interviews were conducted for validation of analysis results and to understand weaknesses of the study.


Screen Shot 2016-02-19 at 1.05.27 PMScreen Shot 2016-02-19 at 1.03.38 PM


Screen Shot 2016-03-18 at 12.12.36 AM

Relative Effect

Screen Shot 2016-04-11 at 10.48.30 PM.png


  1. Focus on a motivated workforce to ensure top talent is retained. Lack of job satisfaction is primarily why they consider leaving.
  2. Focus on the nature of the job. What they do and how much responsibility is afforded to them are the key predictors of job satisfaction.
  3. Train supervisors to provide an empowering environment. Perception of how enabling supervisors are, contributes significantly to job satisfaction.
  4. Offer competitive salary to retain top talent. While salary is not as strong a predictor of job satisfaction as the nature of the job, responsibility, and satisfaction with supervisor, it still shows positive association.
  5. Do not hesitate to employ IT professionals born outside New Zealand. There are no significant differences between New Zealand born IT professionals and those born overseas.

Research invitation: Motivation among IT professionals in New Zealand

Motivation among IT Professionals in New ZealandI am currently undertaking research on motivation among IT professionals in New Zealand as part of my MBA. I would welcome your input. Complete the survey and be it to win two $50 vouchers. More than happy to share my findings with anyone that participates. Feel free to pass on the survey to anyone else you think may be interested too.

SurveyMonkey Link: Motivation among IT Professionals in New Zealand.

Agile or not?

Agile-Or-NotProject delivery in the IT space is a fun job. You get to do interesting things, usually no two things are exactly the same and in the process get to play with technology. Life couldn’t be better. That is until you run into some oddities. Agile methods have not been everyone’s cup of tea. Ambiguity is the enemy of most bureaucratic environments. Before committing to any spends, they want assurances in triplicate exactly what they would get for the project, when, and in what manner. By definition killing any agility.

What is interesting is that some of these organisations appear to be embracing Agile, but not because they want continuous improvement, or are looking to deal with ambiguity differently. They have found the dreaded requirements analysis phase of a waterfall project does not necessarily capture the requirements correctly, and consequently deliveries do not meet the outcome they set out to. Pushing that detail to be worked through in an Agile development method makes perfect sense.

Pushing the resolution of ambiguity later in the development phase means at the project initiation that ambiguity still remains. So any contracting for those services can only give you an estimate to a particular level of detail. What I find in many cases is there is little room for ambiguity when contracting for those services. The bean counters still want to know exactly what you will deliver, when, and how – so when the auditors turn up, they can show a clean bill of health.

As IT practitioners we have done a good job of convincing organisations of the benefits of Agile deliveries. However, we are yet to convince procurement that effort estimation is relative to the ambiguity that has been clarified. Wherever bureaucracy is involved, there appears to be a mismatch of expectations. It is not helped by IT companies willing to do business sometimes ignore their practitioners to take such projects and perpetuate this expectation.

What are you finding out there? Is this the norm or the anomaly?

Image credit:

%d bloggers like this: