20130127-044155-PM.jpg

Application Management Pricing – Not Easy Ground

The challenge of pricing – for an IT service provider

While an end-to-end management approach provides a competitive service advantage, it can carry a substantial additional – and often unforeseen – cost and risk. The challenge is that it’s difficult to estimate the costs of all downstream variables and potential problems. It is for this reason most software providers work on a Time & Material basis, whether it’s for, say, creating a custom application or the migration of a set of applications onto a new enterprise platform (e.g. porting legacy accounting, inventory and reporting systems into a new ERP solution).

The inevitable – and frequently unforeseen – management and consultancy requirements that typically crop up during a project are usually charged at a day rate, which can become a very risky exercise as costs and timescales creep higher.

What this service provider needed to know was whether offering a full life-cycle management service and incorporating all aspects of service delivery management (including these unforeseen professional services requirements) made sense as a viable business model.

Could it be realistically packaged on a fixed price basis while safeguarding the provider against loss? Finding the answers to this question was what lay at the heart of the study, and involved an in-depth research and drill-down analysis.

Read all about it here

http://blogs.computerworlduk.com/management-briefing/2012/09/application-development-pricing-end-to-end-lifecycle-management/index.htm

AGILE & CMM : The Marilyn Monroe Connection (Part 3) : Some Like it Hot!

Here we are at the final part in our hot discussion – will Agile and CMM get hitched, become a potent combination? If you have followed the earlier parts of this story, you would share my excitement – for the fairy tale is within our grasp – what it does require though is a practical mind and the logic to apply to practice.

Let’s dwell a little deeper. Both Agile and CMM share a common set of end objectives – to maximize revenues and reduce costs through faster output and fewer defects, and to enable continuous innovation, to serve business objectives better. Incidentally the same objective every business is seeking, particularly in these difficult times.

So, if we agree that fundamentally their “heart” is in the right place and in sync, what’s then required is to find and select the common pathways to travel down both these methods, without conflict or compromise.

The wonderful part about Agile is that it doesn’t declare “what to do” thereby giving you fair elbow room. And while it prides itself on being lightweight, it really isn’t that simple. Release and Iteration planning needs extraordinary project management skills, working with a talented and multi functional team, who are expected to shed ego and attitude in the cause of Agile. Continuous Integration and Tests ensure continuous verification and validation as well as Configuration Management practices. Not so different from CMM practices after all.

But how about ever-changing requirements? In Agile once Features are finalized in an Iteration Backlog, they cannot be changed. Now that sounds like a Baseline in CMM parlance.

Both Agile and CMM stress on constantly linking Business Value to the Product build, and stress on regular monitoring to ensure. They both constantly review the Return on Investment and measure size, effort, schedules (read Time Box) and cost.  Stakeholder engagement, in continuous and “fast forward” mode, are constantly reviewed in both. At the end of each cycle, a Retrospective captures Best Practices, Lessons Learnt and “What went Well”.

In conclusion, it appears that while Agile and CMM have their differences, they have much in common too. Deployment is never easy and needs to be well guided, not to mention independently reviewed for continuous improvement. With a pragmatic business case to start with, a difficult time is not a bad time to move down the path of software engineering maturity, to deliver the best business value. It may get hot – but then “Some Like it Hot”!

 

AGILE & CMM : The Marilyn Monroe Connection (Part 2) : Something’s Got To Give

In the first part of the discussion, drawing upon the genesis of Agile and CMM, we were left wondering if the two are “The Misfits”, and most likely to disappoint  the pacifists, or can they become soul-mates after all. The conclusion, much like the of Marilyn Monroe’s last unfinished work, is “Something’s Got to Give!”  

Now that we appreciate that these two approaches, Agile and CMM, are prima-facie incompatible, let’s explore some detail about the areas that have gotten us into this debate. The fundamental difference in Agile and CMM begins from the tenets of their methodology and framework.

Agile follows a cycle from Product Visioning, Roadmap, Release Planning, Iterations, Daily Stand-ups, Reviews and Retrospectives. It contains the roles required, the steps in each process at a high level and the exclusions from practice, such as, not using Daily Stand-ups for status, appraisal and so on. It tries not to be prescriptive and allows for flexibility. The CMM also provides the entirety of a Development Lifecycle, and while not explicit, seems to lean towards a “waterfall’ approach. It defines “What” needs to be undertaken, in a prescriptive fashion. Failure to adhere to a “What” specific prescription implies that you don’t satisfy the goals of that particular process area.

Agile recommends embracing and adapting to change. It recommends permitting changes at any time to ensure highest business value and satisfaction. It allows the building of a Release Backlog, which is essentially “product requirements”, further decomposed into Iteration Backlogs, for the purpose of understanding the requirement set being undertaken at the time. CMM, on the other hand, has an entire process area devoted to Requirements Management, prescribing the need to ensure scope creep is contained through Scope Control, which is strictly enforced through the additional rigor of the Configuration Management process area. 

Agile uses several planning and monitoring techniques, such as Release and Iteration Planning, Burn Downs and Burn Ups. CMM prescribes a fairly detailed modus operandi for planning through an entire process area, and follows up with a whole other process on Monitoring and Control. It also requires, at Level 3 maturity, that the entire organization follows a common project management methodology.

Agile does not insist on quality assurance as a distinct process area unlike CMM. However, the nature of Agile methodologies, especially Extreme Programming, presume an ongoing practice of Verification and Validation, through the lifecycle of getting to a “Done” product. CMM on the other hand requires a separate SEPG (Software Engineering Process Group) to develop the QMS (Quality Management system) and a QA (Quality Assurance) group to ensure reviews and undertake audits.

Agile relies heavily upon the human component to have it sail through the traditional “trip over” pieces of design and architecture, inter-group co-ordination, functional expertise, and so on. The CMM model calls for a detailed competency skill set, coupled with training, as a separate Process Area to make up for any resource deficits.

Well, sounds rather irreconcilable, doesn’t it? So can the impossible become possible, will “The Misfits” get hitched? What’s more, can their potent combination be used to bust the recession? Sounds like a fairy tale.

Await the last article in the series, after all, “Some Like it Hot”!

                                                                                                                                 Contributor: Pam Ramalingam

AGILE & CMM : The Marilyn Monroe Connection (Part 1) : The Misfits

If you have begun reading this, you probably have drawn two correct conclusions already.

One, that I am a fan of Norma Jeane Mortensen Baker, professionally recognized as Marilyn Monroe. And two, having worked with both, Agile and CMM, I have witnessed the famous debate on whether they actually do meet, in the end!

It looks like the software engineering community is keen, rather desperate, to ensure that the CMM standard fits into the rather haute couture world of Agile. The Software Engineering Institute’s (SEI) technical note of 2008, “CMMI® or Agile: Why Not Embrace Both!”, makes the proposal in no uncertain terms.

To understand that they are prima-facie ill-suited companions does not need much imagination. Let’s start at the beginning and understand the genesis of each participant.

The Agile Manifesto was written in February of 2001, at a summit of 17 independent-minded practitioners of several programming methodologies. The participants didn’t agree on much, but they found consensus around four main values:  

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In the late 1980’s, the Object Oriented revolution had swept the software planet, and dramatically changed how people built software. Most Object Oriented gurus had a monumental distaste for paperwork, and the cumbersome demands of software approaches, such as CMM, did not appeal. The emphasis was on minimalism.  Software is the alpha and the omega, the yin and yang; all else is merely overhead. The ultimate argument goes like this: “Why worry about artifacts, documents or project management etc., if all that the customer is really interested in is the software itself?”

Now let us examine the fundamental principles of SEI’s popular software standard – the Capability Maturity Model (CMM). Since its introduction by Watts Humphrey in 1989, in his famous book Managing the Software Process , CMM has undergone stages of evolution until now, to the latest CMM Integrated (CMMI) model for software and the relatively less popular CMM for Services. Apart from levels of maturity starting from Level 2 and moving up to Level 5, the CMM is a formal, disciplined and highly structured set of methods, demanding incredible amounts of consistent discipline to run a software programme or project. CMM models absolutely mandate the following:

  • A policy
  • Process relevant to each Key Process Area, identifying pertinent roles, entry-tasks-validation-exit criteria, reviews, audits, metrics, training and tools
  • Procedures
  • Supporting evidence across process and actual operationalization

It is probably a no-brainer, that the two might embrace each other with great awkwardness. In other words, total Misfits, not exhibiting the potential of a happily ever after marriage. In another sense, it’s a typical David vs. Goliath story. For Agile evangelists, the tagline never falters – “Agile means fast, adaptable to change, simplicity, a customer’s dream!”  For CMM evangelists – “CMM means best practice from the cumulative years of expertise, from organizations committed to the business of making software and an objective benchmark”.  Agile development is a minimal, fast-track approach; while CMM is process heavy, bureaucratic and doomed to failure. Agile can never succeed, simply because the concept of a single user representing the customer is not practical or realistic, no more than accepting change at every stage of the development cycle.

Despite the heated debates, and the well-meaning pacifists who believe that CMM and Agile can become soul-mates, what do the astrological charts forecast?

Await the next article in this series. Something’s gotta give!

Contributor: Pam Ramalingam