Category: Working Life

Can a Contract Cope with Changing Requirements?

It's been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.

The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.

When all is sunshine and daises this doesn't matter. The time you really really want your written agreements to be right is when things go awry. If you're doing business even with friends & family, it can help to have something in writing.

But how to write a contract for something when you know it's going to change?

This problem came up in a linked-in architects' discussion and I immediately reached for google to find my notes from Susan Atkinson's presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She's been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.

For those not yet convinced that there's anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.

IT Success and Failure — the Standish Group CHAOS Report Success Factors

The Standish Group have been famously (notoriously) publishing their CHAOS Report with IT project success/failure/challenged rates since 1994. "XXX% of all IT projects fail!" headlines are doubtless responsible for their fortuitous fame but they have also attempted to analyse 'success factors' over the years:

1994 1999 2001 2004 2010, 2012
1. User Involvement
2. Executive Management Support
3. Clear Statement Of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision And Objectives
10. Hard-Working, Focused Staff 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Competent Staff
5. Ownership 		1. Executive Management Support
2. User Involvement
3. Competent Staff
4. Smaller Project Milestones
5. Clear Vision And Objectives 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Hard-Working, Focused Staff
5. Clear Vision And Objectives 		1. Executive Support
2. User Involvement
3. Clear Business Objectives
4. Emotional Maturity
5. Optimizing Scope
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution
10. Tools & Infrastructure

Little changes at the top. Executive support & user involvement were noted in the 1970s as 2 main success/fail factors. 'Agile Process' is an evolution of 'Smaller Project Milestones' (the bit of agile that's actually about process is "deliver working software frequently", which is "smaller project milestones" in olde 1990s language). 'Clear Vision and Objectives' is re-branded as 'Clear Business Objectives'

But note the varying evaluation of the importance of the people. At one level technical stuff will get done if and only if you have competent people actually doing it — it's make or break. But so are all the factors above "Skilled resource" or "Competent staff", albeit less obviously so.

Emotional Maturity is new. The cynic may note that the Standish group will sell you an Emotional Maturity Test Kit (the less cynical may say Standish are attempting to address a problem). Actually their analysis of emotional maturity is largely about character and behaviour which may be a sign that the English word 'emotion' has grown in what it means compared to 20 years ago. They include arrogance and fraudulence; I can see arrogance as a symptom of emotional immaturity, but fraudulence may mean "I've considered what counts as getting ahead in our society and it seems to me that taking the company for everything I can get before they take me for everything they can get is the way to go". Fraudulence is wrong, but ain't always emotional. I think "personal maturity" — or just maturity — is the idea they're grasping at. It's about having good people.

Scarcity of essential success factors

But the top factors are not prioritisable. I think they are all essential. Rating one above the other says more about relative scarcity than relative importance. When it's really hard to get competent, skilled, hard-working staff then that will be your top success factor. As it is, good executive support is harder to come by than competent staff. Apparently.

I'd summarise as follows:

  • Good people
    • who know what they are trying to achieve
    • with good involvement & communication with who they're achieving it for
    • when well-supported

will succeed, if success is possible.

More serious researchers point out all that is wrong with the Chaos report, most notably:

  • unlike published academic research, the data we'd need to evaluate the claims is kept private so we can't verify their data or methods.
  • Their definition of success is very narrow and doesn't mean success. It means "cost, time and content were accurately estimated up front". Which isn't at all the same as success except in areas which are so well understood that there really is nothing at all you can learn as you are doing it. That's not so common in technology projects.

For an alternative and probably more balanced view of the 'state of IT projects' I'd look at Scott Ambler's annnual surveys: http://www.ambysoft.com/surveys/

Outlook 2011 Mac hangs with IMAP – Folder Sync

Ignoring all the other problems with using Outlook 2011, one problem I had and solved:
Having set it to use IMAP, I then set the Preferences - Accounts - Advanced - Sync IMAP folders every xxx minutes to OFF.
Which stopped it hanging every 5 minutes.

Software Quality — the Whole not the Parts

Ben Higginbottom makes a significant point right at the top of this question about the Knight Capital fiasco:

Was the Knight Capital fiasco related to Release Management? On August 1, 2012, Knight Capital Group had a very bad day, losing $440 million in forty-five minutes. More than two weeks later, there has been no official detailed explanation of ...

Ben Higginbottom: Nightmare scenarios like this are not the result in the failing in any one discrete components that can be 'fixed' simply and sweetly by improving the process, but by small failures in multiple domains (I'm kind of reminded of a fatal accident investigation). So coding error, gap in the unit testing, weak end to end testing and poor post release testing coupled with a lack of operational checks when live. I can understand the desire for a 'silver bullet' fix, but in any complex system I've never known them to exist.

Sometimes, it's the whole, not the parts, that needs fixing.