Scrum is easy but big IT organizations and the whole industry still have issues with helping Scrum teams to do their job the better way. At the end processes and poor, Scrum is not helping anyone and the software development and the end product are really weak.
The recent Gartner/FEI survey of CFO’s faith in IT is damning and well, frankly, downright embarrassing. IT is increasingly been seen as a necessary cost that fails to deliver the promised benefit. This has been going on for as long as I can remember so what the hell are we doing about it?
As a response to this complete lack of confidence, increasingly CFO’s are taking control over IT by making it a function of finance. That is, IT is being seen as a cost, not an enabler. Remember the 90’s anyone?
And no wonder. Less than 25% the CFOs surveyed felt the IT department “delivers the technology innovation needed by the business,” or that it “has the right mix of skilled people to meet business needs” and only 18% of the CFOs said they thought “our IT service levels meet or exceed business expectations.” 42% of IT organizations now report directly to CFOs, “and that is expected to increase,” the report quotes. Even worse, the Standish Group have shown that of all the businesses who undertake software development projects, only 34% prove successful.
In summary, business people have lost faith so have handed us over to the bean counters to manage. Yes – we are now viewed as a commodity.
I challenge you IT industry – this has been going on for as long as I can remember so what the hell are we doing about it? How are we going to increase customer value, get better at ensuring we are delivering the right things and deliver real strategic value to the organisations who entrust us with investments?
Table of Contents
IT Projects fail very often. Project Management practice does help pretty much
Let’s start with some facts. We know that IT projects fail generally due to either
poor understanding and management of what is actually required (scope)
a lack of support and engagement from the business (sponsorship)
poor human interaction.
In my experience the latter is the key factor: technology projects fail due to people, not due to technology. So let’s address these issues one at a time.
Poor product and project scope definition
This has been the cry of the IT industry for years; “how can we build it when you don’t know what you want?”. This is normally met with “how I am supposed to know what I want when I am not an expert? Tell me what I could have.” This is then normally then met with “anything you want – at a cost”.
This conversation is what business analysts have traditionally made a career out of. We spend thousands of dollars developing a document that tries to capture everything the business person wants. The document takes a snapshot of what the business people think they need at this given point in time. They are then asked to sign this off from here on in change is strong discouraged. Throughout the project, changes in the market or in the customer’s needs are largely ignored or highly discouraged.
Frankly, in my opinion this approach is downright unprofessional.
We KNOW that somewhere between 30 – 60% of requirements change throughout the life of the project. This has been shown in many studies.
We KNOW that business people seldom know everything they need up front. They only really know once they get to use an early version of the product. They therefore need a mechanism to be able to adapt it. Even worse, we KNOW that by taking a snapshot in time that sometimes business people panic that this is their only opportunity so they also load in everything they might need just in case (see figure 1 below).
We KNOW software is intangible.
We KNOW we would not want to be in their shoes, having one chance early on in the project to agree the majority of the features with little ability to change.
We KNOW that only 7% of human to human communication is the content of the message. The other 93% is voice tone, body language and context.
So why is it that we STILL try to capture the businesses requirements up front, in a written document (the 7% channel) ignoring the 93% rich communication channel accept that they will add in a stack of low value feature in case they need them in the future force them to sign this document off passing all the risk over to them strongly resist any changes (scope creep) only involve them at the beginning and end of the project.
No wonder the business has lost faith in IT.
Lack of support from the business and stakeholders. Product development is far behind
We ask business stakeholders to manage our projects the right way to ensure they have the support and resources (I don’t mean people – I mean resources. I don’t call people resources. I call them people.) needed to succeed. Typically business people are nervous about sponsoring IT projects. And who can blame them? So many fail and as they do they drag the sponsors reputation (and career) down with them. No sponsor likes to have their name pinned to a failed project. The most insidious thing of all is that typically the sponsor does not have the information necessary to help correct the project; leaving them to be the face of the failure among their peers and seniors without the information necessary to help recover it.
Sorry traditional project managers, but backwards looking project status reports, issues registers and change requests don’t cut the mustard.
So here’s something radical: how about we start to manage projects with FACTS? Perhaps we could start with empirical data and perhaps we could even try to capture it each and every day? Perhaps we should empower sponsors with FACTS about scope, schedule, cost and quality? Perhaps we could even ALL take responsibility for this as a TEAM! Perhaps – and this is really radical – we could communicate with the business people! Perhaps, we could even work with them daily, collaborating about what it is they need and then showing them this working quickly. And perhaps, God forbid, we could have some skin in the game! Wouldn’t that be radical? Wow!!!
Think about it IT people. If you want your sponsors to represent you and you want the business to have faith in you then damn well step up. Remember the fable “The Boy Who Cried Wolf” or perhaps “The Little Red Hen”. Yes – it turns out you really do reap what you sow.
People in project and product management
People deliver projects. In general, people don’t wake up each day to fail. People like to succeed. It makes them feel good. The best way to motivate them isn’t purely money. They seek autonomy, master and purpose. Create an environment that allows them to find this.
Business people – get clear – and I mean really clear – on what it is your customers need. Get good at telling stories to your Teams about this. Help your Teams deeply understand the customer and how they are going to use the product. They really do want to know.
Managers – learn how to empower your teams. Let the people who know the customer define “the WHAT” and let your teams figure “ the HOW”. Learn how to become a Servant Leader and then get the hell out of your teams way so that they can deliver. Remove impediments that are stopping them. This is the most effective thing you can do. Agile project management was created to support this objective.
Team members –software is a social process. It doesn’t matter how well you succeed as an individual. What matters is how well the TEAM succeeds together. Be prepared to stop and help others. Be prepared to invest time into building the Teams collective knowledge and spirit. There is no point crossing the finish line alone. Think the All Blacks. It’s a team thing.
The richest human communication channel is face to face in front of a whiteboard. If you really must distribute people all over the world then accept you are going to take a hit in productivity and minimise this using the richest communication channels possible.
Science shows us that co-located teams that are isolated from disturbances tend to experience radical increases in productivity. Accept this fundamental aspect of human nature and work with it, not against it.
Human interaction, team support and collaboration are just as (if not more) important than brilliant technical skills. People deliver projects. People have emotions. When experiencing negative emotions productivity tends to suffer. Try to make sure they feel good at work.
A final word. Einstein defined insanity as “doing the same thing and expecting a different result.” So to the insane IT industry – GROW UP. Get some balls and stop accepting the old mantra “but that is just the way it is around here”. If you aren’t prepared to accept the facts about our industry then do us all a favour and leave it.
Stop ignoring the FACTS and start focusing on showing business value early and often. Start putting the business back in control of projects and start dealing with the reality of our predicament: IT projects require collaboration with the business.
Software is a social process.
