True, we can’t promise any beach volleyball but our presenters have plenty experience in their own shifting sands of Process Improvement.  Visit http://www.cmminews.co.uk/2012/conference.asp to see the agenda and make sure you take advantage of the early bird offer. Book before 24th February and get a 20% discount, taking the price to £478 for the two days.

If you’ve attended before you’ll know that the name of the game is candid, pragmatic presentations and 2012 is no different. We have SITA,  BT and Thales among others sharing their war stories on how to reap benefits while in the midst of mounting financial pressures.   Hornbill a small company by CMMI standards are returning to update us on how their CMMI led initiative fared during 2011 when they went for CMMI level 2, and Lockheed Martin on how getting the language right at the beginning can avoid unnecessary conflict, confusion and re-work

If you would like to come along please email marketing@lamri.com or call 01748 821824

In an earlier blog (How I fell in love with a wiki) I outlined the benefits of using a wiki in a small organisation that acheived CMMI maturity level 2 last year.

Was the wiki instrumental in this? Yes. It was key to quickly and easily capturing and disseminating information about requirements and their status, process descriptions, plans, status reports, measurements, issues, actions and risks. It was a good no-nonsense process asset library.

Was it the only tool that could be used by a small organisation?  No. Other specialist tools were used for configuration management, project scheduling,  automated testing and defect reporting/tracking. These provided functionality that would have been too costly for a small organisation to build into or fully integrate with a wiki. Excel spreadsheets were quickly developed as a low cost effective solution for timesheets, quality assurance checklists, resource planning and measurement data capture and analysis. In larger organisations some or all of this functionality is acquired through off the shelf software packages.

Can the Wiki be improved? Yes. Some of the data on the wiki could make more use of spreadsheets to improve overall productivity and maintenace. For example a small organisation would find it cost effective to maintain requirements traceability and estimation workbooks on well designed spreadsheets rather than trying to maintain these on a wiki.

So the challenge for a small organisation with a wiki is to get the right balance between the benefits of flexibility, ease of use, speed of deployment, appropriate functionality and the overall cost of  maintainance, licences and deployment. Above all ensure it meets your process needs.

I was well and truly shocked to see the numbers from the SEI’s PARS system displayed on my laptop. In the past 3 years only 10 organisations globally have invested in CMMI-ACQ to improve their acquisition of products and services to achieve a maturity level rating of 2 or greater whilst CMMI-DEV is into the thousands and the relative newcomer, CMMI-SVC, is almost a hundred.

2009 = 3

2010 = 3

2011 = 4

So the gap between the potential and benefits that CMMI-ACQ delivers seems to me to be disproportionate to its rate of adoption. Why?

I’m sure there are a multitude of reasons but here are a couple I think could be major causes. There is a lingering perception of Capability Maturity Models as being only for software engineering organisations developing their own software?  Certainly the old SA-CMM focussed on software acquisition but surely the introduction of CMMI and the subsequent introduction of CMMI-ACQ and CMMI-SVC addressed this by drawing attention to all of the CMMI constellations. This could be a reason why Chief Procurement Officers are not being properly engaged in the process improvement strategy to explore the benefits of CMMI-ACQ?

Or is it a result of acquisition being driven solely by cost reduction strategies that de-emphasise the need for improved or optimised practices for engaging suppliers/partners throughout a product or project’s lifecycle.

Whatever the cause of the low adoption rates somebody ought to mount an expedition to the lost world to enable us all to rediscover CMMI-ACQ.

CMMI embodies ideas to stop organizations falling into the “one true process” trap. First, organizations must build a “set of standard processes” – enough processes to support the different types of projects that the organization has to deliver. We can think of these types of projects as forming families – for each distinct family there is a distinct standard process.

CMMI goes further and permits tailoring of the selected processes to better fit the needs of each specific project. Tailoring can only occur within permitted guidelines – to ensure that the performance of different projects remains comparable.  In particular, the quality of the work products produced will be comparable across projects.

There is a further allowance for unusual projects.  Recognizing that all organizations evolve continuously and will have to tackle new and unique challenges, projects are permitted to seek exceptions to the standard processes and tailoring guidelines. The only condition is that the project makes a reasonable case for its exceptional behavior and describes how it will perform its work to ensure that the organization’s policies will not be violated.

The way that CMMI is defined means that organization’s that attempt “one true process” are not fulfilling the CMMI requirements – they cannot achieve maturity level 3.

But organizations trying “one true process” put themselves in an even more invidious position. They cannot improve. The “one true process” becomes a straight jacket that is almost impossible to change.

Surely, though, it is easier just to change one process than to keep several processes current? In terms of the amount of intellectual property to be kept up to date, that’s certainly true. But consider the problems from the other side. Different projects need different changes to be incorporated in the “one true process” to make it better suit their needs. The problem comes when these projects requires contradictory changes – one project needs more agility, the other more formality…

Now, which changes are we going to incorporate into the process? If we incorporate more formality, the agile project is disadvantaged.  If we go for more agility, the formal project is disadvantaged.

Very quickly the strains on the process and the demands to change the process become so great, the “one true process” becomes an unsustainable position. The organization learns to support families of processes, or abandons the idea of process altogether.

Avoid rigor mortis, create your set of standard processes today…

Recently promoted to Awful Prostetnic Vogon, Jeltz watched with dismal satisfaction as the Galactic Improvement Fleet moved into low orbit around the Earth. The cheerful panic-inducing yellow of the destructor fleet had been changed to a dull grey – an improvement in Jeltz’ mind. And the ships still hung satisfyingly in the sky in exactly the way that bricks don’t, which made the situation perfect. The appearance of the terrifyingly familiar ships began to cause panic in the streets below – the population of Earth remembered all too well what happened last time these ships appeared in the atmosphere.

“Well really” sighed Jeltz, “you think they notice the change in colour of the fleet and know what it means”

“Yessir!” shouted Low Prostetnic Myrzzz in his best military voice.

“Thank you number 4, there’s no need to shout”

“Nossir!!” even more loudly.

“I better try to reassure them, I suppose. Put me on the planetary announcement link”

With a vastly disproportionate rumbling in the bowels of the ship, a small transmitter extended itself about 30cm from the base of the huge ship.

Bzzz, crackle, screech. The Approximately Universal Translation circuits engaged.

“People of Earth” Jeltz’ voice echoed through the atmosphere at just the right pitch and volume to give anyone who heard it – that is everyone – a severe headache.

“I know that our last meeting didn’t really go very well, but that was hardly my fault, you could have travelled to Proxima Centauri and registered your protest against the hyperspace by-pass.”

Cries of protest from the surface could just be heard through the body of the ship.

“Oh, come on humanity, let by-gones be by-gones, eh?  After all you got your planet back eventually. Twice, actually. Here it is, better than ever – just think of all those new fjords that were put in around Africa.”

The protests from the surface reached a still higher volume.

“Now look, people of Earth, we’ve gone to the expense of changing the colour of our ships. You should know that we aren’t a destructor fleet anymore. We have been reclassified as an Galactic Improvement Fleet.”

Outside, screams of protest change into a questioning lack of comprehension.

“Oh, really, get a grip. You all know that the Galactic Improvement Team (GIT) at Galactic Central has formed a strategy to improve Earth and the rest of Solar System, to move you into the New Millennium.  We’ve set you mandatory performance goals and everything.”

Sounds of shouted denial penetrate from outside the ship.

“Well now, look here, if you can’t be bothered to read your hyper-mail, it’s no wonder you don’t know what’s going on. Anyway it’s too late now. We have just completed our first appraisal of Earth against GIMME. I have to say you haven’t done very well. Carry on at this rate and it will be back to the destructor fleet, you know.”

“Now look, Earth, it’s hardly our fault that you haven’t invented your hyper-mail client yet – you have to start making an effort, you know. And, really, claiming you don’t know about GIMME – the Galactic Improvement Method for Moderating Existence.  What did you think all those UFO kidnappings were for?”

“Well really, they weren’t just kidnapped, you know, they were the interviewees for the appraisal.”

“Anyway some of the interviewees did ok – they were the ones we returned mostly unharmed.  But there was an appalling lack of evidence. Despite all our hyper-mail requests, we didn’t receive a single document from you. We couldn’t find any trace of hyper-net activity and as for your entries in the guide, well ‘mostly harmless’ doesn’t get you very far in an appraisal, I can tell you”.

Cries of hysterical protest amplified from the surface.

“Now look, I don’t want to have to take this approach, but all the improvement plans are in place.  Of course we can’t let you have any extra resources, so you will just have to carry on doing all the things you do now and fix all these problems at weekends or overnight. After all you don’t really need sleep – you should be evolving beyond it by now.”

“What do you mean you don’t know about the plans? Really humanity, I expected better from you than this. Here we are trying to help you moderate your existence and all you can do is claim you don’t know anything about it.”

“Of course it’s up to you. But if you don’t achieve GIMME Moderation Level 3 by the middle of next year, the Galactic Improvement Team will have no choice but to shut your operation down.  If they make that decision, I will have to get all these ships re-painted yellow.  So come on Earth, pull your collective socks up and get on with it, will you.  Otherwise, I’ll be back. And so will the Destructor Fleet.”

There is nothing to prevent the use of both Project Management and Agile development for a successful completion of a software or systems development project.  However, a distinction between the two is required, in order to understand how to use each of them, as well as to set the
right expectations.

Project Management is about management processes that are enacted to define, plan, manage and successfully close a project that is initiated for achieving a certain set of business objectives.   The project might include development work, which calls for application of one or more particular project lifecycles – for instance software development.  The role of such a lifecycle is to define what technical work is required, in what sequence, what are the technical procedures and skills required to complete it, as well as some other technical directions.

Whereas the Project Management processes are the same for each and every project no matter its technical area, project lifecycles – or more specifically, development lifecycles – are very particular to each application area.  Agile development methods fall into the second category, as they are concerned with technical activities, roles and skills required to develop a software product or a system.

Bridging Project Management and Agile development into a successful process framework is possible, but requires a more subtle approach,
as well as a mindset change for both categories of practitioners.  Things like scaling, working with multiple Agile teams, organizational integration and relationship between development and business levels are of much importance whenever an organization is thinking to embrace Agile development in a consistent manner.

We shouldn’t be surprised that two major Project Management organizations – PMI and APMG – have recently released certification programs
for the so-called Agile Project Management.

Hopefully, we are seeing an outbreak of common sense that will lead to real world integration of existing best practice.  Here’s to hoping.

I really need this new project delivered, but I don’t have the resources to do it.

Well, there’s an obvious solution, why don’t we outsource the development?

And so begins a tale familiar to many in the IT industry. Identification of suppliers is followed by negotiation of contracts.

Well, we’ve never worked with this supplier before, so we need to make sure we pin them down to a precise delivery. Contract terms define what has to be delivered, when and at what cost. Procedures for the negotiation of change are put in place.

Now as the customer, I’ve got a really good feeling. If the project is successful we get the system we want at the right price. If the project fails I don’t have to pay. Fantastic, risk has been transferred to the supplier.

But let’s examine the situation in more detail. The contract has been negotiated early in the project, chances are we know the scope for the delivery, but not the detailed requirements. At best, then, the estimates on which the project budget has been set are very rough approximations. Yet the contract has been structured to form an iron triangle – imposing fixed scope, duration and cost. Of course, the supplier will have added margin and contingency, but the best we can say is that the supplier can have limited confidence of being able to make a margin from the contract.

So now with our new found confidence, we start taking steps forward with the supplier. The requirements are investigated in much more detail, revealing deeply hidden complexity, or facets of functionality that were previously concealed by high levels of abstraction and lack of analysis. The supplier is in a no-win situation. Fixed duration and cost, and a scope that is suddenly larger than they thought – victim of the iron triangle.

Back to the Future

This no-win situation exposes the fallacy of trying to transfer risk in this way. The supplier has a choice – struggle on or give up. In either case there is a pretty good chance that the customer will not end up with the solution they want – they are exposed to a new, operational risk. Because the impact of such a risk will last for a long time, the financial costs are likely to be far greater than those associated with the original risk – even if the supplier pays penalties for failing to deliver.

The risk transfer fallacy is exposed – risk is not transferred to the supplier, it is transferred to the future. Of course, this type of transfer has value too, but not the same type of value that a full risk transfer would provide.

Share the Risk

If the total transfer of risk is illusory, is there someway the risk can be shared and reduced at the same time. Paradoxically, the failure to reduce risk is caused by the very mechanism designed to ensure the transfer of risk – the iron triangle.  To successfully share risk, both the customer and supplier must strive to relax the constraints that are normally imposed by the iron triangle.

Fundamentally, we are talking about a more agile approach to acquisition – an acknowledgement that some problems remain hidden when agreements are put in place; that work during the project will require initial assumptions to change; that the customer and supplier must collaborate, continuously, throughout the life of the project. These mechanisms must be established in the agreement between the customer and supplier.

Balancing Scope and Cost

The iron triangle has three dimensions. In order to balance the agreement for both parties, we will typically need to provide flexibility in two of these dimensions. In place of fixed scope, the agreement defines a strictly prioritized scope. In place of fixed cost, the agreement defines staged payments as increasing function is delivered.

At its heart, this is an agile approach, but agile with a payment schedule. As in all agile approaches, the focus across the work is on the delivery of operational functionality. The supplier has an incentive to deliver as much as possible of the entire scope – this increases revenue. The customer has an incentive to collaborate closely – this maximizes the delivered scope.

We avoid flexibility in the third dimension. As in agile projects, timescales remain fixed, with delivery stopping on the agreed date. At that point both parties are free to negotiate what happens next.

Risk Is Shared

So now we have genuinely shared risk. There is still some chance that the agreement may fail completely – but both parties have strong incentives to ensure this does not happen. If there is hidden complexity, the customer receives less functionality and the supplier receives less revenue. If the collaboration is successful, the customer receives more functionality and the supplier receives more revenue.

The key elements for success are:

• clearly prioritized scope
• payment aligned to delivery against prioritized scope
• a fixed end date.

People CMM was first released back in 1995 amongst the first explosion of CMM’s that followed the SEI’s release of the original Software CMM back in the early 90’s, however in all the excitement of integrating multiple CMM’s into the CMMI, People CMM kind of got left behind.

That it got left behind can be seen from the number of suppliers licensed to deliver services worldwide … only 14 out of some 450 who deliver CMMI services, and of those 14, only 7 actually have staff licensed to deliver People-CMM services.  Another dimension on this is SCAMPI Class A appraisals delivered against People CMM.  Over the last three years there have been just 13 whilst for CMMI over the same period there have been – lets just say many 100’s (see SEI PARS database for the full list).  There is also a high bar to service delivery as certified individuals cost something like 35k USD to develop.  So weak pull from the market combined with weak push from the supply base results in stagnation.

On a related note Chris Webb from Thales gave a thought provoking talk at CMMI made Practical 2010.  His premise was that CMMI was helping them be more predictable and effective via the consistent use of process.  However if one applied the same focus to the ways one nurtured one’s staff then Chris argued that it may well be possible to unlock an additional 20% capacity within the organization.  Which comes around to my discussion above and that maybe there is a commercial demand for help from People CMM after all – its just poorly understood to date.

On this same subject a little bird has told me that the UK, Indian and Chinese governments are starting to express interest in its use … who knows?

The answer should be derived from the way we want to measure the business effectiveness of CMMI programmes.  The ultimate goal of process improvement is to produce a positive change, which should be reflected in measurable benefits.  If managed as “business-as-usual” operations, the risk is that the benefits they deliver get “lost” and the improvement effort becomes seen an an operational overhead.

A closer look at any CMMI initiative will lead us to the conclusion that we’re actually dealing with a series of projects: temporary endeavours undertaken to create unique results.  The fundamental concept of Project Management is to connect the management strategy with a sound business case established upfront, for a given set of business objectives.  These must be expressed in quantifiable measures so that the derived project objectives can be tracked and monitored in alignment with business drivers.  These measures (or KPIs) should be the glue that links business with the technicalities of any given process improvement approach: what we want to accomplish, how the project results will support achieving these objectives, and ultimately, how will we measure success and benefits.

The real reason you need to do this is because it will make the benefits of the CMMI initiative transparent.  By considering what benefits you are looking for you will build measures to enable you to see them.  The sad punchline for many CMMI projects is that they fail to do this and are considered failures from a business perspective.

On the face of it the answer would be yes as standards like ISO9001, EN9100 etc have a pretty good overlap with CMMI. However on doing a bit of digging its not quite so simple …

Analysis we have performed with several of our customers over a number of years suggested that actually the overlap of interviewees was quite poor and thus a combined event presented few benefits. However what got them excited was the realization that folding the improvement initiatives together under a single business improvement banner would deliver significant efficiencies and reinforcement of process based working into the organization.

One of our partners in the certification business has tackled this a different way by seeding a ISO Lead Auditor into a SCAMPI appraisal and then reusing the output to help shrink the ISO. However they do not report big savings.

NorthropGrumman have published an experiment where they combined an AS9100 audit with a CMMI SCAMPI B. Utilizing their model proved it is clearly possible, however it ‘costs more to execute’ as the ISO team participate for the duration of the SCAMPI due to the incremental and consolidating approach taken by SCAMPI.

In conclusion it would seem that combined event savings are not quite as promising as they might on the face of it appear to be. However to my mind the big benefit is in combining the improvement programmes into one. This seems so obvious but maybe there is just something in human nature that means that time and again I come across customers who deal with ISO with one hand and then turn to CMMI with the other and treat them separately. Clearly there are sound business reasons for the multiple standard/model approach. However isn’t it one of the key tasks of business improvement to mask this complexity from the rest of the business?

I had the pleasure of attending several sessions discussing the practical realities of working with Agile in corporations and the practical realities of anything larger than a few people.  In these sessions there was an abundance of common sence and real world pragmatisum which encourages my view of the future for Agile.  There are still the “religious” Agile types but they are being pushed to the fringes which is a great thing.

My colleague Mark was presenting on his 5 lessons from Agile in the Huge (you can get his presentation at http://www.lamri.com/resources.asp?RGID=3&RCID=2).  This was hugely well received and generated over 30 minutes of questions and debate.

One of the interesting things that came to me at the conference was about recovering agile projects.  Lamri have been commissioned on a number of occasions to help recover Agile projects that have got into trouble, we have NEVER been commissioned  to recover an Agile project based on DSDM.  My advice to anyone thinking of picking up Agile, take a serious look at DSDM – I know this is not empirical evidence but I don’t see them challenged in the same way or as often as other Agile based projects.

Remember this when you are planning it … otherwise you spend money on unrealised benefits. unfortunately these are unnecessary expenditure and will make it harder when you ask for management’s support in the future.

Do it properly…..

The in-house team are becoming more sophisticated in articulating what “better practice means for them”.  Now they don’t want to “lose the practices that CMMI has helped them embed” – however they have looked at a number of the Agile practices and have said to themselves that they “could use a bit of that.”  They want to become less “waterfall” and be more “agile.”

However there concern is that they may have to leave CMMI behind at this point – which they don’t want to do because it has really helped to date and why cant they get the best of both worlds?

The good news is that they can.  To be honest you have always been able to, its just that the CMMI model language and examples were not exactly “agile aligned”.  However things have moved on quite dramatically over the last few years.  Just as Agile has moved from niche player to be part of the mainstream, so the latest version of CMMI (v1.3) has evolved to make explicit its welcome for Agile.  The new version of the model is peppered with references to Agile and practical amplifications and suggestions explaining how particular CMMI practices can be addressed in an Agile environment.

You can buy the new CMMI book if you would like to read more, or download the new version of the model from the SEI website here.

Flying Aeroflot via Moscow was… interesting – no in-flight entertainment, so my books got a good pounding. Minimal in-flight announcements – fantastic, Aeroflot becomes my airline of choice. If only they flew more routes from the UK. Changing flights in Moscow – the KGB still seems to run the transfer desk. “Who are you? Where are you going? Where did you get these boarding passes?” Just for starters.

Arriving 7am Saturday morning – the real red-eye experience. The client has arranged a pick-up, so I don’t have to think about finding a taxi. Fantastic. Straight to the hotel, where in brain-dead mode I check-in, unpack, then find breakfast. Interesting slope to the floor in the bathroom, still it helps the water in the shower to drain away. As long as I don’t get too drunk, I probably won’t fall over. No change there, then.

Saturday passes in a haze of jet-lag.

Sunday. Final preparation and some work for the office, so not a lot of chance to go sight-seeing. Make it out of the hotel for an hour or two to get my bearings. Find Subhaktar square and the parliament building – right next door to the hotel. Interesting combination of mid-20th Russian communist monolithic and extreme modernism in the architecture. Hmmm.

Dinner, read, then bed, ready for the off with the client on Monday.

Monday. Getting to know you day. Executive overview of CMMI for the client. These folks are really keen, so that’s great. Some good English skills too, which is fantastic, since I have the Mongolian ability of a senile snail. Lots of naive questions of CMMI – that’s great too, very few preconceptions so we can really bring our expertise to bear. Really tired at the end of the day, so dinner, then sleep.

Tuesday – Thursday – the Intro to CMMI Dev course. Really quite worried, it can be a loooooonnnnnggggggg experience even for people with English as their first language. But there’s a lot of enthusiasm around the room. We take timeouts so the client team can have discussions in Mongolian then sum it up for me and ask some relevant questions. OK, this is working pretty well. The days go on much longer than usual because of the need to take it slow and have local discussion, but that’s OK too.

Wednesday, one of my contacts invites me out for the evening. We travel to the edge of the city and see a huge golden statue of Bhudda, and above that the memorial to the Russian-assisted revolution led by Subhaktar. Then to a local restaurant for some very European food. Actually, that’s ok, I’m still at work tomorrow so I need a degree of caution.

Thursday sees the end of the course. Everyone gets their certificates. Good Job! Discussion and questions after the end of the course. Then I get taken out again. This time to a show of singing and dancing – definitely laid on for the tourists, but a chance to see something of the local culture.  Really appreciate the show. Then dinner and a visit to a local monastery – another huge Bhudda.

Friday. Planning day. What comes next? Well the client certainly has conviction in what they want to do. Maybe their plans need to be grounded a bit more with some real expertise, but it’s really good to see enthusiasm in place of the oh-so-normal-cynicism found back in Blighty. A good opportunity for us to support our new friends in their pursuit of better ways of working.

Out with the senior management team in the evening to enjoy a final dinner. Presented with gifts – one for the office and one for me. Fantastic. Finally an opportunity to try some local food and beer. Take the risk of flying flush-class tomorrow.

And so to bed. Not too late because I have to be up at 4:30am to check out and get to the airport. Back on the Aeroflot flight, this time in rear-gunner class (one up from flush). And I get an empty seat next to me, marvellous. Zzz all the way to Moscow. Read quantum physics between Moscow and London – well some of the time anyway. Back home by mid-afternoon (UK time).

Sunday – sleep till mid-afternoon.

What a great opportunity. To visit a country I guess I would never have got to in my life otherwise. There can’t be many places on Earth so different from the UK. And who knows, if we can continue working with our new friends, perhaps I can go again and get to see more of this exciting country. Better still, at the end of it all we will have helped our client become the first ML3 organization in Mongolia. They certainly have the motivation.

Why “One Idiot” I hear you ask?

Its from a Mongolian Proverb “One idiot can ask more questions than 10 wise men can answer”. Well I certainly asked enough questions, so I guess I must qualify as an idiot.

But at least I’ve been there.

Instead, what we see is lots of esti-artists (no alcohol involved) displaying shocking symptoms of chronic optimism. So here at optimists anonymous, we are developing new techniques to help these poor sufferers, and the organizations that look after them. With lots of care and hard work, we can teach these sufferers to satisfy the predictability junkies at the top of the organization.

Where do the symptoms of chronic optimism appear from? Well first most sufferers are woefully unaware of the actual work that has to be performed to deliver a project successfully. Plans contain interesting tasks like “Do Testing” – a task lasting for 6 or more weeks, but without any more details. And, oh by the way, what about things like “Write Some Tests” and “Put Stuff Right”.  Doh!

We may not be able to fully specify the project plan on day 1. That’s why we see so many modern agile methods stressing prioritization, incremental delivery, backlog management and other techniques. These techniques mean that we need to plan in detail only for the coming increment (sprint, iteration…) and that we deliver the customer’s priorities first managing the risk of overrun.

Maybe if we were able to learn from what we did last time, and improve on it too, we could at least get a good picture of the work that has to be done in the project. Perhaps by recording the work that is actually done by the project, we can compare this to the plan and learn about the things we forgot to put in. Maybe we can even have consistent ways of solving the same problem, so that we can be confident that we know the work that will have to be done by each project as we plan it.

By making sure we don’t leave anything out we will at least have some time set aside for all the work the project needs to do. But, will it be enough time?

That brings us to the second cause of chronic optimism – the inability to consistently estimate the effort involved in delivering the planned work. Sticking a finger in the air and using random number generators are not very effective ways to achieve consistent, useful estimates. So how can we help esti-artists to estimate more effectively?

How about have consistent ways of doing estimating too? So if I produced one like this last time, but this one looks a bit bigger and a bit more complicated, I can look at how long it took and add a bit on. For frequently repeated tasks, I could even formalize this approach using a spreadsheet to make it genuinely repeatable.

Perhaps I could talk to my colleagues and see what their view of how long it needs is? Techniques like planning poker can provide an excellent basis for estimation – looking for consistent judgement across the members of the team.

Whatever, I can create several estimates, establishing the ball-park then pick a reasonable number somewhere in the middle of the ball-park. As I get better, I hope the ball-park will shrink.

So therapy for esti-artists here at optimists anonymous encourages them to think about the previous experiences. What work did you and the team really have to do last time? How much effort did you really need to deliver that work? This time is it bigger or smaller? Is it more complicated or less?

We also encourage our esti-artists to keep track of how they actually perform. Next time round, they can use this information to reduce the size of the estimation ball-park.

No more chronic optimism. Oh, and let’s steer clear of chronic pessimism too. We really can deliver, you know.

Some in the organisation understand what this will yield in terms of business benefits, but most will hear that they must change the way that they work, with no real understanding of what they are trying to fix or why.  So I ask the question why are we talking in terms of CMMi and not in terms of business needs or problems?
This in my opinion is a critical point of any improvement.  Let me explain.  The project managers are busy delivering projects in the same way they always have.  They are driven by successful delivery and are reporting progress against time, cost and quality.  The measure being used for the desired CMMI level is not in any of these terms,  and is therefore perceived to be outside of the bounds of delivery (it’s not by the way).  Project managers and staff see the journey to the mystical level 3 as a hindrance to the actual work of delivery.  They now have to perform the delivery work and the improvement work in the same timeframe they previously had only to perform the delivery work.

The essential element that is missing at this point is the link between any improvement work and how it helps the act of delivery,  with respect to: time, cost or quality.  Because this link is missing then there is no reference defined that people can relate to the improvement need to their daily work.  This leads to a set of processes being developed to support a model view of the world and importantly disconnected from the processes used to delivery products.

Enter the Technical Improvement Professional,  this is someone versed in improvement techniques and technical delivery.  They can talk to the organisation in purely delivery terms,  but can then relate this to a model.  Just like a mechanic,  they understand how the engine works and hence can fix it,  you just know that the car is no longer working right.

Spending only a short amount of time with any development/delivery community will yield a comprehensive list of the problems that they are facing that actually hinder delivery.  This is typically always expressed in business terms. Engineers saying that they often have to rework aspects of the delivery due to a lack of understanding of the requirements,  and hence the delivery is often late, can easily be related to an overall business goal of “we need to deliver our projects 10% faster in order to gain a 20% market share.”

Let’s look at an example:
Embedding a technical improvement professional into the project or development area to help resolve the business problem of requirements clarity will be seen as helping the project to deliver. 

An approach is to show people how it is done well by way of example and then allowing them to take over the practice.  The professional could be using requirements management and requirements development practices to help shape the solution that just helps to resolve the business problem that is at hand.  While there are further benefits to be had by looking at using the whole of the CMMI areas, this is not necessarily what the business needs or wants at this time.  Any improvements therefore need to be bounded to solving the problem and only the problem.  

This may expose other problems, but here is the point they are other problems, which may or may not be causing problems to delivery. This may feel like a very blinkered approach, but the organisation can see directly how the change being made has resolved the delivery issue and supported the business.

Interestingly only the Technical Improvement Professional ever knew that the organisation was infact using aspects of CMMi to help shape the solutions to the problems being faced.  Delivery team members can get behind this kind of change as they can easily identify what is in it for them. They will be changing only those things that are already causing them a problem with their primary job.

Kind of sounds like the right direction to choose to me when setting out trying to use CMMi as a model to support your business improvement.

Once upon a time, I was young and promising, which provided plenty of opportunity for attending leadership development courses.  My peers and I filled in questionnaires and some HR consultants then placed us on a “spectrum” which ranged from “people person” to “analytical”.  Fun memories: the programme director revelling in his lack of interest in people and the managers most detested by their staff always coming out at the people end.  “People person” and “analyst” are so vague they can mean anything and anyway they are not opposing ends of a continuum.  This entertaining exercise was based on creating a false dichotomy between “people” and “matter” (or sometimes “facts”).

The false dichotomy becomes a real problem when trying to effect change.  The changes we work with involve matter (processes, metrics, technology) and people (behaviour, capabilities and culture).  The false dichotomy can lead one into dangerous places:

• Most typical and dangerous: excluding either people or matter:
  • Introducing a new process where the behaviours of the processes users directly conflict with what the process is trying to achieve = failure.
  • Building capable people but not codifying what makes them great into company systems or processes.
• Better but still not right: attempting to split out people and matter into separate changes – this is typified by an organisational change programme that comprises a distinct workstream to do culture change.

A much better approach exists.  A business problem or opportunity impacts upon matter and also people.  But these are so interlinked that it does not make sense to try to split these into separate types of change and tackle independently.  All sides of the business problem/opportunity must be tackled together, say changing processes and culture at the same time.

The good news: you will need fewer people to effect the change.  Some consultancies have built the false dichotomy into a business model and will sell you a team to do the process stuff and a team to do the culture.

Next time I’ll take this argument into metrics, an area that I am helping several organisations with now.  Metrics is surely one topic that must be left to those at the ”analytical” end of the spectrum…

http://onefte.com/2011/05/14/why-cloud-is-the-future/

The conference was bussing – packed with real people from real companies, networking, listening, learning and sharing (have a look at the photo’s here).  To emphasize this point the Norwegian Armed Forces presented BT’s Steve Haighway with a small plaque to thank him for sharing his experience leading the BT DFTS CMMI improvement programme with them.

CMMI is not just for huge organisations, CMMI is Agile Improvement – Hornbill Technologies presented a compelling description of the rapid delivery of significant improvement within a small development team of less than 30 staff.  Hornbill discussed how they rapidly delivered a series of short improvement iterations, each of which delivered tangible improvements to the business and allowed the team to flex and change the improvement journey based on experience and the evolving appreciation by management of “what being a better organisation” actually meant for them.

To really improve you need to change your culture – Thale’s Chris Webb openly shared details of the Thales UK CMMI journey and described how it was underpinning key business objectives of reducing the cost of non-quality and increasing predictability.  However Chris made the point that changing process and systems was just the first stage of an journey that needed to reach up through changing culture, behaviors and lastly personal engagement to deliver an organization that could dominate and sustain. Interestingly the Norwegian Armed Forces also echoed many of these points in their talk.  On the subject of culture, we were privileged to hear Gerry Sweeney (the founder and CEO of Hornbill) discuss clearly and simply why he chose CMMI to drive improvement in his business.  Intriguingly Gerry mentioned during his talk how the development team he started the improvement programme with almost all moved on during its course, necessitating him hiring replacements.  Gerry emphasised that the reason for this was that the culture of the organisation changed over this period from a firefighting, reliance on heroes to a more measured, far more predictable ‘engine’ capable of reliably and economically delivering the technologies required to underpin Hornbill’s product set.  In addition over this period, Gerry physically reorganized the company to support the improvements he was seeking.

CMMI is all about Business Benefit – this was a massive recurring theme as speaker after speaker discussed how aligning CMMI based improvement with the goals of the organization and planning to deliver tangible rapid change and selling this within the organisation was the secret to getting mobilized and staying the course.  We had compelling case studies from Chris Webb (Thales), Paul Bocca (Hornbill), Mark Smith (ex of Accenture and now with Lamri) and more.

CMMI has grown up – what always made CMMI stand out above other improvement methods/models is the realisation that improvement is not worth a jot unless it can be sustained.  CMMI unlike just about anything else, incorporates extensive guidance on the world class practices necessary to sustain improvement.  And it is this experience that has been harnessed and coupled to best in class guidance on service management improvement (CMMI for Service), acquisition management improvement (CMMI for Acquisition) and lastly cross-business resilience management improvement (CERT RMM).  The SEI’s Jay Douglas also illustrated how CMMI is different from other improvement models – in that it has a governing body that actually collates improvement records from users around the world as well as continually improving the model based on real experience in the field.

All the presentations from this year’s conference are available on the conference web site (www.cmminews.com).