Blog

Agile from Whose Viewpoint?

Thu, 02 Sep 2010 | David Piper

So we all want to be agile.

But whose viewpoint are we taking when we talk about agile? I guess an underlying premise of agile is to give better service to customers by making sure that they get what they want, when they want it, with the right performance and at the right price. Actually I’m not so sure that teams take this point of view when they start trying to be agile. Human nature being what it is, I suspect agility is more about the team’s desire to be on the bleeding edge, working in ways that are funky and fun.

Maybe the four things that customers look for gives us a way of thinking about what it means to be agile – but from the customer’s viewpoint. So what are these four things:

• What they want – function
• When they want it - time
• With the right performance – quality
• At the right price - effort

From the customer’s point of view, they have expectations about what can be achieved in terms of these four characteristics.  If the project delivers in a way that matches the expectations, then the customer’s perception will be one of agility:

The project met the our expectations… The team delivered an excellent job…

In contrast if the project could only deliver the customer’s need in twice the time and three times the price, then the customer is not going to be best pleased.

What behaviours in the team can help to ensure that we achieve the customer’s goals. Exactly the characteristics that are talked about in the Agile Manifesto:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

All of these things talk to fulfilling the customer’s need.  But these characteristics need interpretation in the light of the customer’s needs. For example, responding to change is very desirable, unless the customer has a set of requirements that are pinned-down by legal or other constraints. In this case, we can be seen to be responsive to change by openly considering the customer’s requests – ultimately however, there must be an authoritative voice that is responsible for ensuring that the fundamental rules are not broken.

External and Internal Views

Taking distinct viewpoints gives us a useful tool – we can separate the project’s external and internal behaviours. Whenever we are collaborating with the customer, we need to work in a way that meets the customer’s expectations. Whenever we are working “privately” within the team we can choose the behaviours that best fit our needs - as long as those behaviours do not put the customer’s expectations at risk.

Now our way of working has an interface. At the interface we present the user’s targeted values for function, time, quality and effort. Inside the team, we choose how we can best meet those targets. Some activities may require a degree of formality other’s may not.

The bottom line is just plain common sense – no two projects are the same – there is no such thing as a “single way of working”.

To be truly agile, the team must focus on delivering what the customer really wants.

Learn about CMMI

Tue, 24 Aug 2010 | Andrew Griffiths

It’s one of my favorite times of year…. we are in the midst of planning our latest seminar series, the focus of which will be Setting up for Success with CMMI.  This year we have revived running the seminars across the UK – so Edinburgh, Leeds, Knutsford, Canary Wharf and my old favorite location The Geological Society Burlington House in London.  The Burlington house date (20th September) should be the most interesting as we have managed to assemble an excellent panel for the Q&A session of

• Paul Morgan, Director of Technology, TargetFollow Estates Ltd
• Steve Haighway, PMO and Business Improvement Director, BT DFTS
• Ric Woodgate, Head of Consultancy, BAE Systems AEI
• Frank Johnstone, Head of Delivery, Lamri
• Keith Bray, Managing Consultant and CMMI Lead Appraiser, Lamri

To see all the dates and book your place visit http://www.lamri.com/seminars.asp

Hope to see you there!

Process improvement: a white water river

Mon, 23 Aug 2010 | Frank Johnstone

Writing in the July-August 2010 Harvard Business Review, Roger Martin described successful strategy implementation as a ‘white-water river’ where ‘those in charge make broader and more abstract “upstream” choices, and employees downstream are empowered to make choices that best fit the situation at hand’.

This metaphor is pertinent to operational performance improvement.    Without clear and unambiguous direction from top management, nothing will happen.  However, it is only at working level that the particular challenges associated with establishing a new management system, process or tool can be navigated.

Too often I see process improvement programmes without forceful direction (extending Mr Martin’s analogy, these are akin to backwaters that meander for a while before drying up) or where all the implementation details are centrally planned from within the programme, meaning that there is little chance of the programme navigating the operational terrain successfully.

SCAMPI interviews: be prepared!

Thu, 19 Aug 2010 | Regis Blandin

I am supporting an organisation through a SCAMPI appraisal.  Evidence collection finishes this week (see my post Start with the end in mind) for details about how we tackled that.  When immersed in preparation it’s easy to forget that the appraisal is a means to an end, not the end in itself.  I’ll use this blog to share learning points that will help your organisation get the most out of its appraisals.

I am coaching everyone who will be interviewed during the appraisal.  Controversial?  It’s something we’ve always done however at one time we would be a bit secretive about this.  Although we told people “the appraisal is not an exam”, we were behaving just like it was and worrying about preparation seeming like cheating.

Let’s dispel any controversy.  A rigorous appraisal (a SCAMPI A or a detailed SCAMPI B working in verification mode) uses interviews to back up and elaborate on conclusions already reached through reviewing documents.   Pretending a document is produced isn’t going to help when the appraisal team says “show me”.

Interview coaching helps the appraisal reach reliable conclusions without frustrating the appraisal participants by putting up a host of inaccurate statements at preliminary findings.

A good appraisal team will avoid CMMI jargon, but the way the questions are asked may be unfamiliar to the interviewees.  An interviewee needs to know that it’s up to the appraisal team to communicate the question in a way that the interviewee understands.

Employees have low level gripes.  These are often top of an interviewees mind and can come out in response to a question from the appraisal team asking “what one thing would you change about the organisation”.  Not helpful for the process improvement programme if the top answer is “parking spaces”.

Some appraisal participants will not have been in this situation since formal job interviews and will need to be put at ease.

My coaching sessions cover:

• Simplified overview of the appraisal process.
• How to prepare (e.g. “know what documents were submitted from your area and be prepared to talk around them”).
• Practical do’s and don’ts (e.g. speak about opportunities for improvement – some people feel they are letting their organisation down if they don’t say everything is perfect).
• Example interview questions – so people can get an idea about the typical format.

These sessions result in relaxed interviewees who treat the appraisal as a collaboration exercise, which means the appraisal provides reliable conclusions without frustrating the organisation, which means that the organisation gets more return for its investment.

Efficiency and Reform Group

Thu, 12 Aug 2010 | Graham Dick

In the light of the latest well publicised e-Borders problems with delivery it is interesting to note that cross-government operational functions such as procurement, IT, project management and others have been co-located within the Cabinet Office Efficiency and Reform Group led by Rt Hon Francis Maude MP.   This is a welcome step as from my perspective within private industry why should the Government be different from any other large business?

For government the implementation of policy and more topically savings is critically dependent upon the predictable delivery of IT.   Lets face it the simplification of the tax system for example will require software (and lots of it) to implement the new regime.   In a similar manner business critically depends on IT to enable it to function efficiently and often as the core of the products/services they sell.  Sooner or later a business realises it needs to get smarter and more consistent in the way it goes about developing or acquiring complex IT because the cost of getting this wrong critically impacts its competitiveness.  In the business world this invariably leads to a focus on consistent process based working across the organisation, which enables transparency and accountability and provides an environment within which improvements will stick.

Within the business world a respected and proven approach to achieving this is by the use of the Capability Maturity Model (CMMI) which has been proven over many years to deliver significant efficiency, quality and schedule related benefits.  Interestingly my colleague Andrew Griffiths has just been pulling various benefit figures together in his “Benefits of CMMI” blog – they make compelling reading.  Government regularly states how it must learn from private industry – perhaps now is the time?

Do what you think you have been doing

Tue, 10 Aug 2010 | Frank Johnstone

Many organisations are restructuring or downsizing.  Some people thrive on this:

• New top managers.
• Middle managers who find relevance “helping our people through the change”.
• The workshy who find space to hide.

Restructure often leaves things different, not better. Perhaps this is part of the attraction – one can’t expect improved performance too soon – the change must “bed in”.

Organisations have been doing this kind of fundamental change regularly since the 1980s. It has become a way of life.

Do you work in an organisation that must cut its cost base or do more for the same cost?  Let people know there is an alternative to the big restructure – it’s radical because it happens so rarely: make your existing assets work. Get the return on your previous expensive change programmes.  Do what you think you have been doing.

Organisations have invested millions of pounds of their capital buying tools or developing processes. The processes are not used so no return is being achieved on that investment. These organisations are ripe for “make it work” change.

As process is made to work, useless process is managed out. Smarter work practices are brought in. Practice and process become more effective together. Often organisations redesign process to become more theoretically effective but because no one follows the process it’s throwing good money after bad. Compliance is unsexy; but it’s prerequisite of effectiveness.

“Make it work” change is not traditional continuous improvement. It’s differentiated by being a finite task. There is an end point when the process will be working. That should be soon.  Consequently, “making it work” is managed more aggressively than continuous improvement. It should be managed as closely as restructuring.

“Make it work” change is not confined to process. It can apply to human assets (employees to us). When I was a permanent employee, each new CIO would start his tenure with a restructure. One CIO took the novel approach of confirming that the existing structure remained in place… but everyone had to deliver more effectively in their roles. People left. A very few were managed out through performance management. A few jumped before they were pushed. More found roles that better fitted them. Has he restructured on arrival, the organisation would have lost a different group of people. It’s not really different to managing out ineffective process through experience rather than through a theoretical idea of what will be better.

Benefits of CMMI

Fri, 06 Aug 2010 | Andrew Griffiths

A number of weeks ago I wrote about the potential cumulative benefits of CMMI being 68 billion dollars (link) and today I found myself trawling through an SEI report and a couple of end user presentations (BT and Thales) where benefits are mentioned.  The purpose of my trawl was to find some numbers which were believable and the stories around them had a good context.  One of my personal favorite organisations for this data in the past has been Accenture, but somehow people don’t relate to information about them.

From the SEI report there is the excellent chart relating to General Motors (see section 4.2.3).   “General Motors organizations met their schedules more consistently when they made the transition to CMMI models. The number of project milestones met increased from about 50 percent to about 85 percent. Similarly, they reduced the average number of days late, from more than 50 to fewer than 10.  Notice that the major shift in both charts—most noticeable in the second—occurs after they shifted to using CMMI models”

I spoke to my colleague Graham Dick about General Motors and they are, despite the publicised issues facing them, committed to the use of CMMI.  Graham was recently exploring benefits information and he spoke to Rich Frost Global Director Systems Development from General Motors he said some interesting things

“We need to be the best customer we can be in the face of massive outsourcing, CMMI-ACQ is our tool of choice to address this need”

“Indeed 80% of projects are on time and there are very very few flagship projects that fail”

BT DFTS invested in CMMI and ran a programme to achieve CMMI ML3 which has it’s investment severely curtailed at the start of the recession (like most improvement initiatives).  The last year figures relate to the benefits they achieved within one year of starting this programme, this years figures are what they have achieved given a limited investment.

Part of Thales UK had some great results too:

2009 Outcomes

• Identified some £1.54M savings/cost avoidance with £950k in year realisable
• CoNQ within the Thales 2011 target (2% of sales)
• On-time: Production was 80% ended at 94%
• On-time: Dev was 75% ended at 82%
• On-time: Services was 88% ended at 96%

Chris Webb, the Improvement Director responsible, makes some excellent points.  Not least of which that it is hard to really know where you get the actual benefits from.  He sums this up in his presentation by asking did CMMI deliver this? and answering no!  The real point is CMMI is a great supporter and facilitator but other things come into play too.

It’s great to see people reporting real benefits which make a difference to their businesses, if anyone has any more good stories please share them here.  Also, if you like a bit of limelight could I recommend you contact us about presenting at CMMI made Practical next year.

Start with the end in mind – bring appraisal preparation forward

Tue, 27 Jul 2010 | Regis Blandin

I’m still often surprised to find organisations delivering CMMI without application of project management discipline.  As well as not “walking the talk” an unstructured approach decreases the chance of the organisation getting return on its investment.  That’s a wider topic for another time; today I want to share a practical tip, derived from sound project management.

Bring appraisal preparation forward early into your CMMI journey.

At some point in your CMMI journey you will conduct a formal appraisal.  Perhaps a SCAMPI A, if achieving a rating is a business goal; alternatively, a rigorous, evidence-based SCAMPI B may suffice if you just want to objectively evidence the business improvement made.  You will need to collect evidence for each of the CMMI practice requirements within scope.  By the time the appraisal starts, you will have prepared a comprehensive file, mapping the evidence to the CMMI practices.

My tip is simple and based on experience of what’s worked: bring this appraisal preparation forward early into your CMMI journey.  What does this involve? 

I run a series of workshops, structured around the CMMI process areas in scope.  In the workshop (for example Project Planning), I walk through the CMMI practices with the operational people from the relevant functions and projects.  For each practice we agree exactly what evidence will be provided by that project or function to demonstrate that the practice requirement is met.  Taking a coaching stance and getting the project people to think about what they do that meets the practice requirements is a great way of transferring detailed knowledge of what the model is expecting to see: making it real.  The output of the workshops is effectively a specification of “how we do CMMI in this project/function”.

The workshop can be followed by technical assurance on the evidence to confirm that it does indeed meet the practice requirements.   Before the appraisal itself, the evidence will be refreshed for currency – for example replacing a historic status report with a more current status report.

If you see your appraisal as your major milestone, then this approach manages the risk of failing to achieve the milestone.  You identify any areas where operational practice falls short of the CMMI requirements at a point when there is enough time to fix.

In terms of timing, don’t leave these workshops too late.  However, a level of CMMI understanding and operational maturity needs to be in place before the workshops are successful.  Otherwise you will risk “missing the wood for the trees”.  An organisation that is just starting with CMMI should be focusing on fixing the big gaps.  Workshops like I describe can follow about six months into the journey.

Software Development Project planning and estimating survey

Fri, 23 Jul 2010 | Andrew Griffiths

Way back in 2004 Lamri ran a series of seminars focussed on the business of planning and estimating software development projects.  We preceded each seminar with a short survey and then published the conclusions after the seminar as a resource on the Lamri website.  I think news yesterday of challenges on the ‘Trusted Borders’ project prompted me to wonder if the state of the art as actually practiced has moved on since 2004.  So with your permission I include the same survey questions we asked back in 2004.  They are simple and short so I invite you to complete the survey by answering each question and hitting ‘Vote’ after each.  I’ll write up the results in a few weeks and post back.  Many thanks in advance!

Thank you very much for completing this short poll.  I do confess it is simplistic but its the same questions we asked back in 2004 so for consistencies sake ….  By the way if you are interested in seeing our 2004 report have a look here at Major Challenges to Software Projects Survey.

Buying CMMI services

Fri, 23 Jul 2010 | Andrew Griffiths

I have spent the better part of my working life in the process improvement business working as an internal change leader, a consultant and as a salesman.

Over the years I have seen some interesting situations relating to the procurement of process improvement and CMMI services and I just thought I would put together a summary of my two personal favorites :

Consulting services are not paperclips

I bet you are thinking this is a little obvious, but believe me it isn’t to everyone.  The number of times clients write up RFPs / RFQs with their approach to applying something which they do not have the right skills and experience to deliver is amazing.  The requests can read something like:

“Acme company have a target to achieve CMMI ML3 we have never done this before and we lack the internal skills.  Please give us a firm price for the execution of the attached project plan and by the way we would like to hold you accountable for the successful delivery of CMMI ML3.

PS the right answer is £XXXX if its more than that, its bigger than the budget we had approved for this and you will be qualified out of the procurement process”

I bet some of you are smiling now… Interesting situation this.  The client clearly has failed to consult with the market and build at least a modicum of internal knowledge such that an effective procurement can be done.  They will make the wrong choice.  Any supplier who tells them the truth about their situation runs the real risk of being qualified out at the first hurdle.  Those who say nothing or say “yes Mr Client” will be left in the process.   There is only one outcome, the price will be change controlled up by the supplier…. but not on day one…. when the client is completely committed to the supplier.  My policy is to be straight with clients about this and, more often than not, it gets you kicked out of the process in round one!  However, we are often picking up the pieces of these poor procurements when the client feels the pain of their choice at a later date.

The mechanic problem

Why is it that when you have completed a baseline appraisal of an organisation where you clearly identify all the gaps in their capability they feel the need to tell you how to go about fixing them?  Its a little bit like going to a garage with your car and saying:

“There a problem with the steering at 40 mph and it shakes can you please diagnose the problem”

and after the garage diagnoses the problem as a faulty steering rack you say:

“Actually I think the most effective way to fix this is…….”

No one feels the need to tell their mechanics how they should approach fixing the car, why do IT professionals feel that they know how to fix problems that have often been endemic in their organisation for years?  The more surprising perspective on this is that their company has paid for professional advice on addressing an issue why try to undermine it?

I guess part of the problem is with a car if you look at an engine and you know you don’t know what you are looking at and you know you need help.  IT professionals think they know how the engine works but they do not know the process of fixing it and for some reason they think this is easy.

Another way of thinking about this is:

If you change someone’s way of working how long will it take?

• You need to design the change
• You need to communicate the change
• You need to check that they have changed
• You need to alter the quality system to lock in the change
• Maybe some of the people need some close support as their capabilities need improving

How long is that?

Large Government IT Solutions

Thu, 22 Jul 2010 | Graham Dick

Another one bites the dust or so it seems – according to BBC News the lead contractor on the UK Trusted Boarder has just been let go.

I guess my reaction is firstly a suprised “wow where did that come from” as even up to the end of last year the programme was moving to schedule according to reports in Hansard and Computing.

However on thinking about this one realises that this illustrates one of the classic symptoms of immature programme governance, i.e. “the eleventh hour show stopper that seems to emerge from nowhere”.

There is a clear need beautifully articulated by the never ending procession of significant issues with Government sponsored “big IT Solutions” for a systemic approach to ensuring lessons are learned and the capability of customer and supplier to incept, manage and deliver these programmes dramatically improved.

We only have to look across the water to the US sponsored CMMI (for acquisition and development) for a piece of the answer.

Adopt a “sales perspective” to measuring customer satisfaction

Wed, 21 Jul 2010 | Frank Johnstone

In this context, we’re interested in the perception of senior executives who pay the bills rather than the end users.  Senior executives know the business objectives: a system that is unfriendly to use may be fine if it was cheap and delivered fast.

The customer survey can be approached from two perspectives: “quality” or “sales”.

The quality perspective prioritises obtaining accurate measurements results, which can be analysed and to identify process improvements.  Implementing the process improvements should better customer satisfaction.

The quality perspective is exemplified in government contracts, where the customer satisfaction surveying may be conducted independently by the Office of Government Commerce.  One major systems integrator recently switched responsibility for customer satisfaction measurement to its quality group to avoid their customer relationship managers influencing the scores upwards.  With mixed results: some customers do not want to see an unfamiliar face; to them, introducing the quality group has just complicated their supplier relationships.

Organisations that adopt the sales perspective set out to influence the scores upwards.  Here, the survey could never be completed by the customer offline and would not involve the quality group on the front line; it is completed during a discussion between an account manager (salesperson) and the customer.

The account manager goes in prepped on the successes of the contractor or IT department and understanding of what’s gone wrong.  The account manager presents “what we’ve done for you”.  The customer then provides feedback.  The account manager tries to mitigate negative points.  Following discussion the customer scores his or her satisfaction.

An in house IS department was getting feedback so negative it was almost vitriolic through a survey developed from the quality perspective.  They redesigned the survey from the sales perspective.  Customer satisfaction went up quickly and substantively.  Here’s why:

1. The conversation around the survey gave the customers a different perspective.  They saw that supposed cost overruns were directly attributable to them introducing new scope.  And actually, architected solutions did enable them to launch new products faster, as well as increasing the cost first time round.
2. The conversation around the survey was rich: it explored themes and ideas.  The qualitative feedback elicited drove innovative process improvements.
3. Finally, because the conversation was a positive experience, the customer ceased regarding the survey as a meaningless tick box exercise and started to see IS’s genuine desire to improve.  Doing the survey directly improved satisfaction.

CMMI – The Buyers Friend – part 2

Mon, 19 Jul 2010 | Graham Dick

Just a short post building on my previous thoughts.  I’ve found the following helpful “Guide to Supplier Appraisals” on Supply Management’s website at http://www.supplymanagement.com/resources/how-to/guide-to-supplier-appraisal/.  Its written from the professional buyer’s perspective and discusses a rationale for when it would be appropriate to appraise one’s potential suppliers.  Within the context of this community – appraisals often comprise commercial scrutiny, evidence of quality standards such as ISO and some evidence of technical and managerial competence.  From my perspective an interesting point is that clearly the buying community understand how challenging largely bespoke IT developments can be.  They also appreciate that its abundantly good practice to put prospective supplier’s under considerable scrutiny.   On the other hand over in our Development pond it is a truism demonstrated with concrete evidence that CMMI does improve and does drive improved predictability, reliability etc.  In other words a large slug of the characteristics that our professional buyer is looking for.  Why then are these two worlds so far apart? Why when assessing appropriate IT Development “heavy” acquisitions does the buying community not make use of focussed CMMI assessments to gain an deeper understanding of a prospective supplier’s actual capability to deliver the “thing” they are bidding to deliver?  I appreciate there have been scattered instances of this but the curious point (to my mind) is that nowhere on the professional procurement related sites is this outlined – even if just from the perspective of here is a useful tool given the appropriate environment.   As ever thoughts welcome …

CMMI – The Buyer’s Friend?

Thu, 15 Jul 2010 | Graham Dick

CMMI has always struck me as a bit of a funny old thing.   What I mean by that is that to those ‘bought in’ to process based working and best practice it is almost literally a no brainer – to almost everyone else it is like luxury goods – take it or leave it the world will go on.   An area that we have gained little traction in is in the area of acquisition support.   Just google the words supplier appraisal or supplier assessment and there are loads of helpful sites that speak from the perspective of the procurement/acquisition professional and discuss those acquisitions where the ability to really understand the true technology development capability of a potential supplier is critical to the acquisition decision but also to helping the acquiring organisation really appreciate the risk associated with that acquisition.   They discuss how the procurement team will often incorporate one or more relevant technical experts who will often perform some element of technical due-diligence on the prospective supplier.

From my (almost certainly heavily biased perspective) this strikes me as yes but.   ‘Yes’ for acquisitions that contain technology which is reasonably straightforward.   ‘But’ for acquisitions where the technology is novel, the product critically dependent on it, perhaps the requirements not fully understood and the supplier’s capability to deliver being critical to success.   In this latter environment there is an approach that will provide more transparency and objectivity.   Instead of relying on the good experience of a small number of individuals wouldn’t it be helpful to incorporate the experience of thousands and use an assessment method that is truly objective?

This is where CMMI comes in.   CMMI incorporates best practice taken from literally hundreds of successful developments (worldwide) and condenses that experience into a crisply articulated set of requirements that good technology development process should meet (so defining what your processes should achieve not how they achieve it).   The model comprises best practice for technical and management processes combined with best practice for ensuring an organisation’s processes are widely adopted and enduring – not just a flash in the pan. Coupled to this is a rigorous assessment method called SCAMPI, with individuals who are highly trained, licensed and quality monitored in their application of it.

So putting these ingredients together means that when the development capability of a supplier is critical to an acquisition then incorporating a CMMI assessment of the short-list or preferred bidder allows the acquisition team to build a truly informed picture of the real technical capability of the supplier.   In today’s cost conscious climate perhaps using this approach to enhance due diligence may go some small way to reducing the number of large technology focussed acquisitions that fail to meet expectations?

We know we got better but we can’t prove it

Mon, 05 Jul 2010 | Frank Johnstone

Always frustrating when an organisation knows it has got better but can’t back this up with improved performance metrics. This happens for one of three reasons:

1. Performance metrics are avoided as being too hard. The organisation may instead collect, but not use, what is most easily collectable. Often output from tools.

2. A sophisticated metrics repository is considered prerequisite to collecting performance metrics. This achieves the same result as (1), quite possibly wasting £500k on the way.

3. Performance metrics are deferred to late in the improvement journey, by which time much of the improvement has happened. The excellent Steve Haighway from BT has talked about this phenomenon.

Any project delivery organisation investing in process improvement that is NOT collecting performance metrics should rectify this before July is out!  Why July?  Well this is so urgent you need to start now and you can get it up and running within one month.

The following are a great starting point:

Project predictability: % variance from original scheduled delivery date and budget.

What about when the delivery date or budget change? OK. If the reason is the customer (that means the customer funds the change not just we say “it’s the customer’s fault”), then the budget and schedule are rebaselined. If the customer is not funding the change then the actual delivery date and cost at completion are compared against the original delivery date and budget.

What about organisations with internal customers who always pay for the change regardless of why it happened? Again, that’s not a barrier. Several organisations in this situation have adopted most basic rules for classifying changes as customer initiated or self-inflicted by the project delivery organisation.

Customer satisfaction: Using the “quality is meeting and exceeding customer expectations” viewpoint, this is a great complement to project predictability. Do collect the data from the real customer: the senior executive who understands the business objectives for the delivery and pays the bill. (This is not a user survey).

Projects stopped: The first two metrics are about “doing a project right”. This one gets thinking going about “doing the right projects”. Organisations with external customers should choose not to bid for uneconomic work. Organisations with internal customers should refuse to start projects if the requirements are so poorly understood that delivering something that meets customer expectation is a matter of chance. If every bid becomes a project or every project is passed through governance then there may well be a problem. Start monitoring this now and have a look.

Of course there are many more equally meaningful and perhaps more useful metrics to choose from.  Remember I’m speaking with those organisations doing process improvement but not collecting performance metrics and their task is to remedy this by the end of July.

How the Wind Blows

Fri, 02 Jul 2010 | John Evans

I have been commenting on the anti-patterns that hinder successful delivery of business changes. I’m sure that we have all mused about the kind of things that hinder our day to day working. The one I want to discuss today is my personal favourite as the one thing that is guaranteed to cause calamity and a trail of devastation in it’s wake. The dreaded shake up of senior management. This has been brought in to stark relief following the recent changes in government, leaving the people on the ground to deal with the consequences of a drastic change in direction.

My own thoughts on this subject are a little closer to home relating to changes that I see over and over throughout the many clients that I visit or colleagues deal with.

In most organisations where change is successful, there is a strong business driver for change, which is understood and agreed upon in the higher management. This is cascaded down through the organisation and a change plan is developed to make that change happen. The old ways of working are deemed to be unacceptable and the senior management require that the new ways of working are adopted.

 However when the senior management re-organises and the business driver is absent, either by virtue of the re-organisation or lack of agreement then the organisation is at the mercy of the new incumbent and their preferred method of working, generally little consideration is given to the change programme and the impact the changes in management will have. 

The major problem is that this reorganisation and the ensuing chaos as the direction is changed, leaves little of no support for the change programme. This allows the change programme to become optional and subject to the whims  of the masses. Without the strong leadership to ensure that the behaviours of the organisation are changed then the change programme quickly turns to inactivity.

This becomes  problematic when the leadership then allow delivery to take place in the same old ways that it always has, as it undermines the change programme. People start to view the change as secondary to delivery rather than as part of enabling better delivery.  In essence there is no compulsion to make the change from the leadership.  This can have an immediate and detrimental affect on the engagement of staff . Nothing junior staff or consultants can do during this time will be as effective as the senior management requiring that products are delivered in the new way of working. Which, surprise surprise is not top of their agenda while jockeying for position.

Pricing In Risk – Or a lot of knowledge is a dangerous thing …

Fri, 02 Jul 2010 | Graham Dick

There were some amusing off the record conversations a few years ago where it was suggested that a certain household name telecoms company might have clinched a huge multi-year high profile UK government programme when at the eleventh hour a senior exec made a unilateral decision to “just drop a billion” off the bid price.  Now I’m certain this call was not as unconsidered as I have portrayed it, but it all came flooding back to me when I was talking with a prospective customer the other day.   The individual in question confessed that he used to work for a UK division of one of the major US mil-aero operations and whilst there his organisation was one of the last bidders for this same major contract – running its bid according to CMMI best practice, pricing in risk, working with realistic worked estimates etc.  Surprise surprise they did not win the business!

This disguised anecdote backs up a common anomaly found when selling highly bespoke products – namely pricing in all the risk (even as contingency) and building in realistic estimates is often a bad plan unless the entire customer selection team is as mature as you are.  Only then are they well placed to recognise that perhaps the cheapest bid is not the best bid.

This little anecdote bares some similarity with Paul Morgan’s post of a couple of days ago – how do you work ‘by the book in a sustainable and mature fashion’ when your customer does not know what he does not know.  Sometimes its just wisest to give the customer maximum credit for his self perceived maturity and then deal with the inevitable fall out when it happens!

As Paul also said – I’d be interested in your opinions?

First Day ESEPG

Tue, 29 Jun 2010 | elporco

Arrived! It is bit quiet today, but things really kick off tomorrow with the bulk of the delegates arriving. Going to find out about the 360 project manager today sounds like an interesting topic.

Catching up with old friends from the SEI and Steve from BT.

So far me and my friends have been a huge hit at the conference, demand is outstripping supply… Need to send for reinforcements! Must hide in case I am picked up by the madding crowd!

Roving reporter El Porco

On Tour in Porto

Mon, 28 Jun 2010 | elporco

Just arrived in sunny Porto and looking forward to the ESEPG. Me and my team of valiant Lamri pigs are making our way to FEUP. We have got a tough few days ahead meeting the delegates and pressing the flesh. Not to mention the exciting presentations! My human colleague Neil Grover is presenting on a complex multi model issue.

Well time to head off and setup for tomorrow.

El Porco out!

When Process and Customer Service Collide

Thu, 24 Jun 2010 | Paul Morgan

The scenario below is a fictitious but I have no doubt that it plays itself out on a regular basis in the real world.  In our story the e-mail below was sent in response to a request from a client for information about whether a certain project could be done and, if so, by what date.

Dear Tom,

After some discussions with our Software Development department, it has been decided that I need to submit a formal “Business Request” (BR).

What this means is that in accordance with their CMMI compliant processes Software Development will need to size the change and submit a price and time estimate. It also means that the process has been taken out of my control and therefore I can no longer guarantee that I can get as timely a response.

The normal process for our Software Development department is to meet once per month and gather the BRs they have received and talk through the pricing estimate. If the business decides that they are willing to pay the price Software Development has given us, then the work goes into the queue to be scheduled.

The project is placed in the queue based on a point system, which weighs importance, level of complexity, and the resources required to work on the project and their availability.

At this time I cannot guarantee that I can meet your timeline.

Roger Smith

Director – Customer Sales

XYZ Co.

Clearly this is a missed opportunity and if we ratchet up the stakes by suggesting that the company makes tens of millions of pounds a year from the relationship with the client then this adherence to process not just isolates the Software Development department but brings it into direct conflict with the business.

We all realize that there needs to be an orderly and structured approach for dealing with Software Development requests so what is it about this scenario that doesn’t quite sit right. Well I guess it’s because all the customer was really asking for was a time and cost estimate for the project, and the long, drawn-out process described in the e-mail to get to this simple answer just doesn’t cut it.

So what would you do? I’m sure that nearly everyone reading this blog has to contend with this very question on a regular basis.  So rather than tell all of you what changes I think this particular company should make, I’d like to take an opportunity to learn from your collective experience.

How would you advise this company to change its process in order to be more responsive to critical customer requests? Would you:

• Make the Software Development meetings more frequent?
• Make those meetings collaborative with the business?
• Eliminate the company’s point system?
• Have the business submit a request with certain date and budget parameters from the start?
• Something else?

The value in hearing from everyone on this topic is not so much in finding THE answer, but in generating some conversation and in exposing a variety of possible answers, each of which has its place, depending on the organisation and the specific situation involved.

Acknowledgement:  Thanks to Marc J. Schiller for a posting on the Tech Republic blog site which I have adapted for our CMMI world.