I enjoyed Frank Wander article on the IT Failure and the Dehumanization of the Workforce. He discusses important factors that need to be considered in the development of software, and how many large projects are not delivered in budget or on time. One of the major factors that contribute to this is the practice of treating the IT worker as just another component of the project and not accounting for the human side of the equation. What does this mean? I have broken down some common areas on projects that discount the IT resources as craftsman and which can contribute to software project failure:
1. Resource productivity and discounting talent – This happens all the time in the hiring process. Procurement is bringing on resources and has no ability to gauge the productivity of a resource. Instead they focus on driving out costs which leads them to hire average skilled resources. Every team still needs a LeBron James or Dirk Nowitzki and you are not going to get one with a vendor rate card, it does not work that way in in the sports world or in IT.
2. Lack of detailed breakdown of development tasks – After the design process when the team or teams of IT resources are working on a project, one big driver is failing to break down all the development tasks into fine grain detail. You will hear “It will go faster if I don’t have to write things down and I just code”. This is never true, when you are working during the day, your always get more done when you are working from a list of action items or tasks. Just trying to keep all the detailed tasks in your head is not effective in anything that you do. Also what contributes to this factor is that during the course of the project more tasks are discovered as more information is understood about the project details. Without an accurate ability to capture these tasks and prioritize them with the rest of the work that is already in the project scope, these additional tasks can impact both cost and the project timeline.
3. Team continuity – As Wander points out in his article the human factor of the IT worker is extremely important. But in today’s IT workplace how many project teams work together past the implementation of one or two projects. In life when do teams come together for the first time and execute the best they can? The answer is that they have to practice together and execute together to understand each others strengths and weaknesses so they can all work better together as a team. This factor is often overlooked on large project implementations as resources are staffed to fill headcount numbers and not how the individuals with make the best teams.
While I have highlighted some of the factors, there are many more.
What do you think is important for success project delivery?
Good points made here but I wonder about how we define success vs failure of a project? Is going over budget or longer time a failure if we deliver value to the business? If we deliver on time and on budget, but the product is cumbersome or ineffective- can we chaulk that up to a win?
You hit on one of the toughest things to accomplish in IT and coaching – productivity of the individual vs productivity of the team. I have seen, and I know you have too, times when you have a resource doing say 30% of a teams production. Take that resource out and the teams production goes UP. I have seen it the other way as well, the team ‘glue’ who doesn’t ‘do’ much-but remove him or her and the team struggles. Maybe he or she had the vision or were the motivation.
I think we try too often to measure success on time and budget when maybe we should look to value add.
Great point Greg. The improvement and coaching of both the individuals and team is a huge component. I would say when the team is engaged you are way more likely to meet the budget and timeline. As individuals work together as a team better I have seen the productivity of each person get better as well, as they also help each other.