I just finished erecting a few non-trivial pieces of furniture in my daughter’s bedroom. She had been asking for new furniture, for a while, and I had been dragging my feet, dreading the inevitable complexity of (i) assembling an order of furniture from catalog piece parts that represented both a complete and aesthetic solution (2) lugging back 8-10 heavy boxes from IKEA (3) staging the boxes in some place other than the small bedroom and (4) assembling the furniture with the risk of broken parts, missing parts, thumb injuries and bleeding fingers from turning knurled nuts onto reluctant screws. But the fact of the matter is that my daughter is leaving for college next September and this is the last year she will enjoy her bedroom as a permanent resident of the Rao home. There was clearly a time WINDOW for her requirements, after which the purpose of the furniture was moot. We were all aware of impending changes to the situation, her needs and the context come August 2010.
It was time for agile furniture development.
With help from my father-in-law and a very close young friend of ours who is also mechanically inclined and adept, we set about the tasks of providing and installing furniture from IKEA in my daughter’s bedroom in a three day time frame. My daughter, busy with schoolwork, could not come to the store to select the furniture. We made phone calls from IKEA to my daughter to get course corrections on our choices of furniture and determine what attributes were not negotiable – the bookcase HAD to have glass doors, for instance. We brought the boxes back, laid them down in our foyer, and set to work with the assembly – a process that lasted two evenings, well, late into the night.
At the end of the effort, when my daughter finally came into her room, she could not control her joy. The room looked airy and spacious and there was light and style everywhere. In business terms, we had succeeded in “delighting the customer”. We had developed a solution within a requirements time window, incorporated needs that were explicitly discussed and exhibited competence and professional pride in executing the tasks that were undertaken.
The fact that more than 70% of IT projects come in dead on arrival, speaks to some deep flaw that is inherent within ourselves – we IT people. When contrasted with road projects that get built, and usually built well, bridges that are routinely constructed, train tracks that are routinely laid, and skyscrapers that shoot into the sky overnight, this IT project failure rate is incomprehensible to me.
I have a lot of suspicions and guesses for why this may be so. Other large undertakings like bridges, skyscrapers, railroad tracks have an already established base of knowledge that makes the planning simpler based on looking at past experience. Once they are commissioned, they move to completion with few dramatic changes but a lot of minor corrections along the way. Funding justification, once obtained, has to survive for the length of the project, for it to complete. The science and engineering is well understood. Meeting the expectations of the sponsor are fairly easy to test once the project is completed. And a number of these projects are either remodels or replacements for existing items.
There are two types of projects in the IT arena. Opportunistic software product development is based on an innovative idea taken to completion in the form of a software or hardware/software product that can be sold in a marketplace. This is the form of software development in the traditional Silicon Valley style startup. The other form is requirements driven software engineering – where the developer is coding to requirements provided by someone else – usually the business sponsor of the effort. The bulk of IT shops that support business and industry, fall into the second category and these are the ones that have demonstrated a 70% project failure rate.
In the IT arena, what we construct is based on requirements. And requirements come from the business. Business changes, often frequently, so requirements must necessarily change. When requirements change, work previously completed may have to be scrapped and new budget allocations are required to staff the changes. When this budget allocation does not appear, we have the classic IT backlog – a number of planned changes on a back burner.
It was time for agile furniture development.
With help from my father-in-law and a very close young friend of ours who is also mechanically inclined and adept, we set about the tasks of providing and installing furniture from IKEA in my daughter’s bedroom in a three day time frame. My daughter, busy with schoolwork, could not come to the store to select the furniture. We made phone calls from IKEA to my daughter to get course corrections on our choices of furniture and determine what attributes were not negotiable – the bookcase HAD to have glass doors, for instance. We brought the boxes back, laid them down in our foyer, and set to work with the assembly – a process that lasted two evenings, well, late into the night.
At the end of the effort, when my daughter finally came into her room, she could not control her joy. The room looked airy and spacious and there was light and style everywhere. In business terms, we had succeeded in “delighting the customer”. We had developed a solution within a requirements time window, incorporated needs that were explicitly discussed and exhibited competence and professional pride in executing the tasks that were undertaken.
The fact that more than 70% of IT projects come in dead on arrival, speaks to some deep flaw that is inherent within ourselves – we IT people. When contrasted with road projects that get built, and usually built well, bridges that are routinely constructed, train tracks that are routinely laid, and skyscrapers that shoot into the sky overnight, this IT project failure rate is incomprehensible to me.
I have a lot of suspicions and guesses for why this may be so. Other large undertakings like bridges, skyscrapers, railroad tracks have an already established base of knowledge that makes the planning simpler based on looking at past experience. Once they are commissioned, they move to completion with few dramatic changes but a lot of minor corrections along the way. Funding justification, once obtained, has to survive for the length of the project, for it to complete. The science and engineering is well understood. Meeting the expectations of the sponsor are fairly easy to test once the project is completed. And a number of these projects are either remodels or replacements for existing items.
There are two types of projects in the IT arena. Opportunistic software product development is based on an innovative idea taken to completion in the form of a software or hardware/software product that can be sold in a marketplace. This is the form of software development in the traditional Silicon Valley style startup. The other form is requirements driven software engineering – where the developer is coding to requirements provided by someone else – usually the business sponsor of the effort. The bulk of IT shops that support business and industry, fall into the second category and these are the ones that have demonstrated a 70% project failure rate.
In the IT arena, what we construct is based on requirements. And requirements come from the business. Business changes, often frequently, so requirements must necessarily change. When requirements change, work previously completed may have to be scrapped and new budget allocations are required to staff the changes. When this budget allocation does not appear, we have the classic IT backlog – a number of planned changes on a back burner.
Given that business change is inevitable, the expectation that IT requirements never change is both unrealistic and simplistic. IT development has therefore shifted from building “monument” style IT solutions to quick and dirty “beach-house” releases that address the requirements of the day, knowing that these will change and parts of the solution must be thrown away.
The move to agile development is partially based on delivering IT solutions within a narrow time window when the requirements are still relevant. The use of centralized deployment using web based solutions is to further decrease the latency between the availability of a solution and its deployment to end users.
I was reading an interesting article in CIO magazine http://www.cio.com/article/502263/Project_Management_How_IT_and_Business_Relationships_Shape_Success?source=CIONLE_nlt_projmgmt_2009-09-24 where a project team was able to accomplish much by close coordination between the business and IT staff. The thesis was “Bad relationships, are a leading cause of project failure”.
I quote and partially paraphrase from that article ….
The impact good and bad relationships have on projects is clear: "Negative relationships make people want to avoid each other or work against each other," says Bill Hagerup, a senior consultant with Ouellette & Associates, a IT leadership and project management consultancy.
On the other hand, when mutual trust exists between IT project managers and stakeholders, IT project managers are more likely to discuss problems that could threaten the project as they arise, says Imholz. If bad blood exists between the two groups, project managers may not be inclined to point out those issues, or they may try to cover them up.
If you look at projects that fail, invariably someone on those projects knew things were going bad," says Imholz. "If you don't have relationships and trust, those things don't surface. And when you don't do something about problems in a timely manner, those problems invariably get bigger. In many cases, minor problems become more serious because they're not addressed in a timely manner. A culture of openness is absolutely essential to good project performance."
Decisions affecting the project also get made more promptly when everyone involved gets along. "Fast and good decisions are crucial to keeping projects on track," says Imholz. "The failure of senior people to make decisions means decisions are made at lower levels of the organization. If you have a software developer who's waiting [for a decision] on a business requirement, there are three things that can happen:
1. He can guess what to do and guess right.
2. He can wait for a decision and while he's waiting he's not as productive.
3. Third, he can guess and guess wrong.
If those are three equal possibilities, two-thirds of the time it will be detrimental to the project. And if you stack enough of those decisions on top of each other, it will negatively impact the project."
The article goes on to speculate whether the background of IT personnel prevents them from recognizing the value of relationships and focus instead on the value of tools and processes.
"As IT professionals, we're raised on technology," says Ouellette & Associates' Hagerup. "Almost all the training we get throughout the years is about tools and processes."
Consequently, he adds, IT professionals think process and technology is the answer to everything, including effective project management. While project management frameworks and tools certainly help, projects are fundamentally people-driven, he says.
Agile development coupled with strong relationships can result in customer delight!
I was reading an interesting article in CIO magazine http://www.cio.com/article/502263/Project_Management_How_IT_and_Business_Relationships_Shape_Success?source=CIONLE_nlt_projmgmt_2009-09-24 where a project team was able to accomplish much by close coordination between the business and IT staff. The thesis was “Bad relationships, are a leading cause of project failure”.
I quote and partially paraphrase from that article ….
The impact good and bad relationships have on projects is clear: "Negative relationships make people want to avoid each other or work against each other," says Bill Hagerup, a senior consultant with Ouellette & Associates, a IT leadership and project management consultancy.
On the other hand, when mutual trust exists between IT project managers and stakeholders, IT project managers are more likely to discuss problems that could threaten the project as they arise, says Imholz. If bad blood exists between the two groups, project managers may not be inclined to point out those issues, or they may try to cover them up.
If you look at projects that fail, invariably someone on those projects knew things were going bad," says Imholz. "If you don't have relationships and trust, those things don't surface. And when you don't do something about problems in a timely manner, those problems invariably get bigger. In many cases, minor problems become more serious because they're not addressed in a timely manner. A culture of openness is absolutely essential to good project performance."
Decisions affecting the project also get made more promptly when everyone involved gets along. "Fast and good decisions are crucial to keeping projects on track," says Imholz. "The failure of senior people to make decisions means decisions are made at lower levels of the organization. If you have a software developer who's waiting [for a decision] on a business requirement, there are three things that can happen:
1. He can guess what to do and guess right.
2. He can wait for a decision and while he's waiting he's not as productive.
3. Third, he can guess and guess wrong.
If those are three equal possibilities, two-thirds of the time it will be detrimental to the project. And if you stack enough of those decisions on top of each other, it will negatively impact the project."
The article goes on to speculate whether the background of IT personnel prevents them from recognizing the value of relationships and focus instead on the value of tools and processes.
"As IT professionals, we're raised on technology," says Ouellette & Associates' Hagerup. "Almost all the training we get throughout the years is about tools and processes."
Consequently, he adds, IT professionals think process and technology is the answer to everything, including effective project management. While project management frameworks and tools certainly help, projects are fundamentally people-driven, he says.
Agile development coupled with strong relationships can result in customer delight!
No comments:
Post a Comment