I think that this oversimplifies – the devil is in the detail. From experience it is about far more than just “the wrong scope” (I’m referring to the project requirements as the “scope”) – it is also about “scope creep,” “scope change” and underlying business change which inevitably results in “scope change.”

If you want to scope a big development at the start of the development, you are going to have a tough choice when the inevitable scope change requests come. Either, enforce the “letter of the law” by referring to the brilliant/bullet-proof requirements documentation you created upfront OR allow the changes and “donate” the work required to the paying client.

Neither option is reasonable. Someone is going to lose out in either case.

There is an answer. It’s called Agile Development. At WWW, we use a particular methodology called “SCRUM.”

The Agile Manifesto puts the issues squarely on the table.

In simple terms: Work in smaller chunks. Deliver business value often. Collaborate with the software owner/sponsor very closely throughout the process. Accept that change is inevitable in software development – accommodate and encourage it. Ensure that everyone on the development team trained and mandated to maximize business value on behalf of the software sponsor/owner. Everyone on the team is both developer and analyst.

White Wall Web recently worked with RE/MAX of Southern Africa to deliver a new digital initiative which “allows sales associates with profiles or accounts on major social networking sites (such as Facebook or MySpace) to add, manage and organise property listings through social bookmarking.” (Read more about this here)

This sounds exceptional from a business value perspective and has generated notable press coverage, but technically, this is one of the simplest implementations we have completed on behalf of RE/MAX of Southern Africa in the entire 5 years of working with them. This got me seriously thinking about maximizing business value when consulting…

Business Value, Complexity and Effort

When doing project work at WWW, we follow the SCRUM process. Three important metrics considered in the planning process are “business value,” “complexity” and “effort.”

Business Value is all about the value a piece of functionality will create in positioning a business to meet it’s organizational objectives.

Complexity is about how complex a piece of functionality is to produce.

Effort is about how long a piece of functionality will take to produce.

Complexity and Effort differ in that two tasks may take the same amount of time (effort) but require a far more skilled person to do the one than the other (complexity). Consider the difference between watching a 2 hour movie vs. conducting a 2 hour heart surgery.

Clients are happy when…

…they maximise business value while minimizing costs. Since both effort (time = money) and complexity (high skill = money) add cost.

Consultant’s Gold

As a consultant/solution provider you have struck gold when you find ways to maximize business value while keeping effort and complexity at a necessary low.

Fight the urge to use all your super powers all the time

As consultants/solutions providers (in any field) we have a great toolset of awesome super-powers. The urge is to use them all, all the time. We are conditioned to think “It’s not good enough to add some simple social-media-bookmarking-tool-bar to a website as a professional and respectable solution.” Surely that can’t be of great value? What will my peers say? How could I possibly do that and claim I have done something noteworthy/worthwhile?

It’s all about what you value

What we value most dictates what we will consider to be most commendable. For example, if you value a healthy family life, you will think that an 80 hour work week is excessive and stupid, but if you value hard work and maximum wealth creation, you will think that a 40 hour work week is lazy and stupid.

This issue is actually rooted in the same. As a consultant/solutions provider, if you value creating maximum business success for the clients you serve, your focus will be on business value creation at the lowest possible cost. If you value the technical implementation of a solution, that will be what you consider most commendable.

It’s also about professional maturity

A mature professional appreciates and celebrates the creation of business value.

It is immature to elevate technical implementation above business value creation because in reality, technical implementation is a means to an end and not an end in and of itself.

The Web Dev Community

As an international and local community, I think we are getting better at this, but we still have a way to go. What I mean is, I recall 3-4 years ago, techie forums (for example) being very heavy on the actual tech used in producing solutions. Some loud-mouths “out there” would lambaste others in the community for their technical implementations (even often when the resultant business value created was high, despite not-too-amazing tech)

As a community of practitioners, we need to continue create a new peer pressure: maximize business value, keep complexity and effort at a necessary minimum.

A developer/technician/consultant who gets this right is a true professional in my view.

“We have just officially entered PersonL (last minute) into this years TechCrunch50 Contest

We had half applied, decided it was too late, and then they mailed me yesterday and asked me to complete the entry by tomorrow…

So we got cracking and churned out a much upgraded web site and content in just two days (planning, writing content and everything).

Well done to the team who did this: Martin (design and input), Pascal (most of the dev and styling), Tim (Powerpoint, Flash and graphics) and Ferdi (making sure it all came together).

Check it out and let us know what you think.

Rob helped out a bit on testing from a usability perspective. I wrote the content.”

The amazing thing is, i think it is the best website we have ever built on such short notice.

So this is how it rolled out… I (Peter) had half completed a very late (only heard about it very late) entry for PersonL on the TechCrunch50 website when the general consensus in the team was “it’s too late.” So I stopped and we focussed again on our 23rd August *internal* deadline to get PersonL out of beta and into commercial-release-still-in-beta-phase .

On of the “background tasks that we just haven’t gotten to yet” list, getting our promotional site up and ready has been sitting semi-permanantly at about number 5. But an email from TechCrunch on the 30 July changed all of that…

So why did we manage to get such a great result in such a short space of time. Some thoughts:

• All the team members involved know our product and business intimately
• We had all the tools at hand (all required technologies)
• We had very fluid and regular correspondence between the business people, the technical people and the marketing people
• We were not too focussed on cost estimates and “big spec upfront” but rather business results best met – basically this was very Agile
• We had a Project Manager on the project with a singular focus on delivering a swift result
• We were all having fun

And was fun! (Note to self, I must work hard to convince more clients to engage with us in this way. It is simply so much better for everyone concerned…)

Now just holding thumbs for TechCrunch50.

My excitement was heightened as I anticipated finding more kindred spirits and some form of debate going on at CeBIT. I headed straight for the Business Processes stalls after my arrival while simultaneously scanning the “Today’s Programme” guide for lectures/presentations on the subject. Instead I found a large Outsource Development/Consulting contingency all touting RUP, Waterfall, MSF and SDLC type approaches (any many derivatives in-between).

This section was also in my opinion one of the least vibrant section of the fair with most visitors passing through while attempting to avoid having a brochure thrust into their hands by eager sales people hoping to land a new client. This was particularly disappointing since there is such a vibrant discussion going on around the subject of software development/business analysis on the Internet and in other forums.

I am relatively new to being so aware of Agile and being a strong advocate and thus perhaps still a bit naïve about these things; but surely if so many of us can see the power of these approaches and consider the debate worth our time and energy, the world largest technology fair should have it tabled as a higher profile issue. After all, if the claims made by Agile project leaders about the success ratios of Agile projects over projects run on other approaches are accurate and true, big ICT spend decision makers ought to sitting up and listening (on the edge of their seats for that matter).

I will continue my quest tomorrow, but for now, I am a bit surprised and a bit disappointed. At the same time, I am keenly aware that this means there is still huge opportunity to do fantastic work in highlighting this debate.

If I suddenly find the Agile stand(s) I’ll let you know…