ITsourcing

AHP and Price Evaluation

Once the AHP tree has been created and weighted, one area that causes a bit of thinking is the criteria to be used to mark the vendor’s price. Let us assume we have four bids priced at: £10M, £8M, £7M and £6M.

My most used formula is: Score=10*(1-(Price-Min)/(Max-Min)) where Min is the lowest price and Max is the highest price. The scores become: 0, 5, 7.5 and 10 respectively. The impact of the scores depends on the weighting of the price element in the AHP tree. If a weighting of 10% is agreed, then the contribution to the weighted score is: 0, 0.5, 0.75, and 1.

Another formula is: Score=10*(1-Price/Max).  The scores become: 0, 2, 3 and 4 out of 10 and using the same 10% the weighted contribution becomes: 0, 0.2, 0.3 and 0.4. This feels like a more fair evaluation. Actually, this formula gives the same results as the first calculation if used with a larger weighting.  If we scale the 10% weighting, used above, with a factor of 10/4, (i.e. using the best scores for the two formulae), we get 25%. Using this weighting the contribution using for the second formula results becomes: 0, 0.5, 0.75 and 1.0.

I have only used the first formulae, letting the weighting provide the required impact. My experience has been that organisations set the price element as low importance when they first agree the AHP weighting; say 20%. However, when the costs come in higher than expected they then want to revisit the price weighting and increase it, often to around 35% - all part of the learning curve…

Ian Richmond
Email: ‘About’ and ‘Email Me’ link

Competitive Dialogue Procedure

Back in March 2004, the European Commission introduced the concept of Competitive Dialogue with the publication of Directive 2004/18/EC. Consequently, the OGC produced a document Competitive Dialogue in 2008.

This guidance document raises the issues of treating the vendors equally during the dialogue phase of the procedure. When I developed guidance and training material for the Revenue in Ireland, I felt the best way to ensure equality was to develop and maintain a set of reference documents for the procurement. These documents would include the Joint Statement of Intent, draft RFP, draft commercial terms and requirement specification. They would be published on a server accessible by the vendors and updated with new releases during the procedure. With suitable version control and email notices to the vendors – issue solved.

Long before Competitive Dialogue was developed, I came across a great tactic which would fit into the Competitive Dialogue procedure. Shell was building an oil blending plant. Internally they had developed a high level requirement for the IT systems that would manage and control the plant; this requirement was perhaps fifty pages in length. What Shell needed was a detailed functional specification against which the IT procurement could be made.

Shell went through a normal long list, RFI, short list process and selected three system integrators (SI). Each SI was then required to put forward an experienced designer who joined a specification team managed by a Shell manager on Shell premises. The SI’s were paid on a T&M basis for their designers. Over a three month period the team turned the high level requirements document into a full functional specification (running to several large volumes).

The team was disbanded and the designers returned to their respective companies and joined the bid team. Shell issued the RFP with, of course, the RFP attached. The now knowledgeable bid teams produced three great proposals. Sema won the bid and went on to implement successfully the solution; there were no surprises and no misunderstandings.

I feel that this ‘Shell trick’ is better than employing a team from another organisation who will not be bidding for the implementation. My experience is that bid prices often differ because the vendors do not have a clear understanding of what is required. The better the understanding, the closer the bid prices become to each other; a win-win for all parties concerned.

Ian Richmond
Email: ‘About’ and ‘Email Me’ link

How to Fail With SCRUM Adoption

When we adopt a methodology, is it reasonable to ‘pick and mix’ the major elements of the technique? A large UK corporation claims it has adopted SCRUM but, when pushed, agrees that it has adopted parts of the methodology, rather than the complete approach.

The software development had been off-shored to India; the Product Owner is in the UK. This means the SCRUM meetings had to be substituted with conference calls, severly cutting down on personal interaction and threatening the integrity of the SCRUM meeting. I have found that virtual teams can work provided there is a sensible mix of telephone conference calls and physical meetings. Doing strategy development, I found monthly physical meetings and weekly conference calls worked very well. For SCRUM based development, I feel that the Sprint reviews need to be face to face to achieve the goals of the meetings.

A core principle of SCRUM is to deliver incrementally, slices of usable functionality; ideally the first Sprint should deliver this first slice. Our large corporation had dropped this basic element. Does it matter?

My experience of reviewing runaway projects is that most failing projects fail because of non-functional performance, rather than lack of user functionality. Arguably, we can add more programmers to a project to add more functionality. However, fixing failed non-functional performance is far from trivial.

Creating a slice of (end-to-end) functionality using SCRUM drives the development team to address the non-functional issues very early. One project I reviewed was three years into a two year programme; the functional specification was agreed but the non-functional requirements were yet to be agreed – it got cancelled.

The end-to-end slice explores many of the grey areas. The early stages of a programme should be clarifying these poorly understood areas.

My conclusion is that dropping a key element of a methodology destroys the integrity of that methodology, putting at risk any ability to enjoy those benefits intended by that technique.

Ian Richmond

Email: ‘About’ and ‘Email Me’ link