Organisations and how they deliver projects or services are a bit like good wine and cheese; successful quality outcomes depend on many inputs. In an organisations case those inputs can be identified as the maturity of people, process, technology and the organisation itself.
What is maturity if it’s not about age?
For me it’s about how developed the inputs are at a point in time to deliver the expected results. The following grid is simple yet illustrates my theory:
- Level 1 = Low maturity over a short period
- Level 2 = Low maturity sustained over a long period
- Level 3 = High maturity gained over a short period
- Level 4 = High maturity gained over a long period
Regardless of how the inputs are evaluated let’s be honest and acknowledge that even if all the stars are aligned there will be pain during a projects life cycle. It would be utterly dishonest to say otherwise. But it takes two to tango and the project is just a vehicle, something created for a given purpose and specific time frame to deliver against a particular set of objectives. The organisation needs to make sure the people and processes assigned are mature enough to deliver. It’s simply not good enough for a business or vendor to say ‘the processes are in place and we have good people’ if those processes are new or over-engineered and the people involved are unable to differentiate between process for process sake and what makes sense. Personally I don’t buy those trust-me conversations.
What can be done to improve maturity levels? Unfortunately there is no magic-wand. Benchmarking is an obvious choice and there are many tools, techniques and consultants ready to help perform comparisons for high fees – some sophisticated and others not. A quick search on google UK for “Project Management Maturity Model” returns over 1 million results in the blink of an eye. Other options are more obvious and pragmatic yet perhaps not as attractive or popular against high-cost acronym-toting methodologies. That’s not to say an industry-standard globally-recognised approach that measures maturity against the big-guns isn’t worth the effort or investment. All I’m suggesting is maturing anything can sometimes get lost as the methodology takes over.
Why not look at what’s physically happening? What are people saying? What are they experiencing? Where are additional processes being introduced because the existing ones don’t work, can’t cope, take too long, or are too bureaucratic? What is being done with or to the technology because ‘it doesn’t meet our needs’, ie: it doesn’t fit with our old outdated processes that our people are too immature in their understanding to recognise. Then make decisions and take action – the two most important attributes of change. Remove people from projects who are clearly out of their depth. Help them find a mentor and give them time to develop. Stop insisting a process is used when it clearly adds no value. Check it out and change or get rid of it. Focus on improving and streamlining those that are imperative to customer satisfaction not internal justification.
In today’s ever changing business environment where the drive is for leaner, faster, more and all cheaper than it was last week, it’s untrue to say that nothing will ever reach maturity. Things do, they just don’t have to be old first.