Bad Software Projects, Bad Management, IA Can Help
There is a great article in IEEE's Spectrum.
It details massive software failures. But small ones matter, too. Heck, just continuing to select Microsoft stuff is a failure, particularly IE and Outlook.
Why do projects fail? The article has this list, and includes more examples and details. Everyone in business should read the whole article, even if they're not involved with IT.
Among the most common factors:
1. Unrealistic or unarticulated project goals
2. Inaccurate estimates of needed resources
3. Badly defined system requirements
4. Poor reporting of the project's status
5. Unmanaged risks
6. Poor communication among customers, developers, and users
7. Use of immature technology
8. Inability to handle the project's complexity
9. Sloppy development practices
10. Poor project management
11. Stakeholder politics
12. Commercial pressures
My own experience is that these patterns are the norm, and only individuals and small groups outperforming any reasonable expectation of brilliance and commitment compensate for these factors.
In fact, I've never been involved in a properly systematic, funded, or stakeholder-engaged project in my whole career.
Don't get me wrong... I'm all for staged, creative, adaptive development. The list above might suggest that the best approach is to know exactly what you are going to do prior to doing it. I'm looser than that. But there should always be strategy, goals, cross-functional input from stakeholders, and top-level buy-in.
But even small projects: Manuals that suck, departmental websites that don't have anything to do with company strategy... no company strategy, nobody to produce content, no approval process for content, adding content development and review to the job description of people who are already working 50-60 hours/week...
In a way, this article is naive enough to suggest that failures are avoidable, because it doesn't account for the fact that most of us live in such an environment.
But no organization should go forward without some commitment to pursuing the ideal, even if the ideal can't be reached. Let's face it, most businesses cannot afford to do it right. They don't have the right staff, and they won't hire them.
Such is life.
How can Information Architecture help?
An Information Architect is more than a visual designer. IA starts with the user... Who is the user? What do they need? How can we make it easy for them?
It is amazing how much focusing on these basic principles can prevent IT disasters. Because in pursuing this information, you get stakeholder involvement, you get good visual and experience design, you get cross-functional design. All are key elements of adoption.
No project should be designed in isolation from this information. No project should be done in isolation from the users.
Yet, I'm asked to do this, all the time. I can't talk to customers, I can't talk to engineers, I can't talk to internal users. I can only talk to the one person who is supposed to know what is needed. And they don't have any specific training or experience in any of these things.
So I ask a lot of questions of this designated person, and I infer a lot. And the result is just OK, by my standards. Fortunately, that is usually better than average, good enough, or kinda great.
This is how these projects usually succeed... Somebody exceeds the limits imposed by the situation, through talent and experience.
It details massive software failures. But small ones matter, too. Heck, just continuing to select Microsoft stuff is a failure, particularly IE and Outlook.
Why do projects fail? The article has this list, and includes more examples and details. Everyone in business should read the whole article, even if they're not involved with IT.
Among the most common factors:
1. Unrealistic or unarticulated project goals
2. Inaccurate estimates of needed resources
3. Badly defined system requirements
4. Poor reporting of the project's status
5. Unmanaged risks
6. Poor communication among customers, developers, and users
7. Use of immature technology
8. Inability to handle the project's complexity
9. Sloppy development practices
10. Poor project management
11. Stakeholder politics
12. Commercial pressures
My own experience is that these patterns are the norm, and only individuals and small groups outperforming any reasonable expectation of brilliance and commitment compensate for these factors.
In fact, I've never been involved in a properly systematic, funded, or stakeholder-engaged project in my whole career.
Don't get me wrong... I'm all for staged, creative, adaptive development. The list above might suggest that the best approach is to know exactly what you are going to do prior to doing it. I'm looser than that. But there should always be strategy, goals, cross-functional input from stakeholders, and top-level buy-in.
But even small projects: Manuals that suck, departmental websites that don't have anything to do with company strategy... no company strategy, nobody to produce content, no approval process for content, adding content development and review to the job description of people who are already working 50-60 hours/week...
In a way, this article is naive enough to suggest that failures are avoidable, because it doesn't account for the fact that most of us live in such an environment.
But no organization should go forward without some commitment to pursuing the ideal, even if the ideal can't be reached. Let's face it, most businesses cannot afford to do it right. They don't have the right staff, and they won't hire them.
Such is life.
How can Information Architecture help?
An Information Architect is more than a visual designer. IA starts with the user... Who is the user? What do they need? How can we make it easy for them?
It is amazing how much focusing on these basic principles can prevent IT disasters. Because in pursuing this information, you get stakeholder involvement, you get good visual and experience design, you get cross-functional design. All are key elements of adoption.
No project should be designed in isolation from this information. No project should be done in isolation from the users.
Yet, I'm asked to do this, all the time. I can't talk to customers, I can't talk to engineers, I can't talk to internal users. I can only talk to the one person who is supposed to know what is needed. And they don't have any specific training or experience in any of these things.
So I ask a lot of questions of this designated person, and I infer a lot. And the result is just OK, by my standards. Fortunately, that is usually better than average, good enough, or kinda great.
This is how these projects usually succeed... Somebody exceeds the limits imposed by the situation, through talent and experience.
0 Comments:
Post a Comment
<< Home