Thinking Outside the Box to Improve Project Success
I have been contemplating the successes and failures of 2007, comparing them to past years. It is interesting to me how lessons that seem obvious sometimes get missed as time goes on.
Technology projects will always contain, for example, a team that knows considerably more about the nuts and bolts of the technology than the average user of the technology. Makes sense if you consider the prospects of a team that doesn’t know much about the technology in question.
However, the disconnect between someone who knows a ton and someone who doesn’t is often … a ton, too. This makes working on a large company project that involves technology difficult unless the two ends understand one another. Andrew Hanenkamp wrote an article entitled Communication from End-User to IT, which address some key ways to reduce this tension. Here are the three key points from his article:
- Examine current processes to engage your people
- Prepare your people for changes early
- Discuss the plan with managers from start to finish
I think these are great points, and if you haven’t read the article, go take a look. Here are three examples from my past (one from last year) that illustrate ways to take the concept a little further.
Examine current processes to engage your people
I worked on a project for a credit scoring company. Their application was used by banks during the lending process to use FICO scores along with other indicators to indicate the health of the lender. The research and data were solid, but the application was full of acronyms, inconsistent button placement and other issues.
After the application rolled out, many of the users revolted and went back to an older application that spit out a score based on just a few factors. In an effort to revive the project, I sat down with two users who showed me (and the developer) how to use the old application, and how to use the new application. We didn’t say a word, didn’t interrupt and took good notes.
I learned why the old design worked so well, and adjusted the front end of the new application to fit. The developer finally saw that the system fit his mind well, but wasn’t at all intuitive for the people who would use it. We went back four times over the next three months, and adherence soared.
Prepare your people for changes early
In rolling out a new version of GoldMine (a CRM package, for those who are interested), I started by training everyone on the current version. This solved three problems with the previous rollout: lack of standardized methods, lack of product knowledge and lack of investment. The training classes started three months before we rolled out the new version, and continued on into the new version. Everyone was used to the format, and the transition was much, much smoother.
Discuss the plan with managers from start to finish
At Boomer Consulting, our executive team meets monthly to keep everyone on board. When I first started attending these meetings, I gave an update of where the technology projects stood. Now I give an update on the projects we decided on from the previous meeting and solicit feedback on the direction for the next month. It’s high level, doesn’t talk about CRM, Sharepoint or MySQL. I use a powerpoint slide of the next six months of projects to talk.
If we need to change direction, everyone who has investment is in the room and can decide to change priorities. We did this last year with postponing some internal upgrades to allow for more work on our CRM implementation. This paid off in increased productivity, and every executive in the room knew of and approved the change.
As I move forward to 2008 projects, I look at these three examples from my past and realize that I don’t need to reinvent the wheel. And, I imagine members of our firm can look at the first two examples and see the origination of how I work technology projects now.
