By Ken Norland
Associate
I’ve been writing about some ways that you can help your IT project succeed. In my last two articles I discussed picking the right project manager and then helping your project manager succeed by ensuring that she is actually allowed to manage. Today I’d like to talk about why you shouldn’t wait until the project is “done” before you get it into the end users’ hands.
IT Project Success Depends upon Meeting End Users’ Needs
If your project is aimed at producing something for end users to use, then ensuring that what you produce is what these people actually need and want is vital to the project’s success. We’ve all seen situations, though, where the delivered project perfectly matches the agreed-upon specs but is not accepted by the end users. There are a few common reasons why this happens:
- End users’ needs evolve over time – If the specs were written six months ago, they probably do not fit the end users’ current understanding of what they need the project to do.
- End users’ understanding changes as the project materializes – There’s a big difference between reviewing static specs or screen mock-ups and interacting with something live. Even if their needs have not changed at all, it’s common for end users to see what the project team has produced and say “Gee, that’s not what I meant.”
- End users change – Sometimes by the time a project is delivered, the people who need it have changed. The new people may want it to work a little differently than what the previous people had envisioned.
- End users and techies don’t speak the same language – It is very common for technology folks to use words in a way that the end users do not. The same words can have very different meanings for the techies, who have a technical understanding of the issue, than they do for the business people, who have a business understanding of the issue. This “language barrier” leads to misunderstandings, which leads to projects that don’t effectively meet end users’ needs.
Seeing Something Live Can Address All These Issues
Getting an iteration of your project into end users’ hands sooner rather than later can help your IT project succeed because it gives you time to update the specs and change course as necessary. This approach is based on the idea of Agile Development – although you do not need to go fully Agile in your development methodology to make this work. One other benefit of this approach is that once in a while, an “incomplete” version may work just fine for the client, and you can finish a project early and under budget!
I do have one important caveat here, though. You need to be sure that the end users who get involved at the early stages of a project’s development are ones who understand the concept of “intermediate results.” Some people will expect to see the full solution the first time they see anything. You need to work with people who understand that what they’re looking at is not the final iteration. It’s going to change, and they’re going to be helping you to make the end product better by making constructive change requests.
Don’t Let Your Corporate Culture Get in Your Way
Particularly in large companies and with large projects, over time there evolves a desire to have everything formally specified ahead of time. The IT organization is then expected to deliver exactly what’s in those specs. People get very binary about it. Unfortunately, this approach can cause a lot of friction between the end users and the development staff or IT organization when it is realized that the initial specifications weren’t of a satisfactory solution.
The approach that I am recommending here is a change from being very “legalistic” (“well, it’s in the specs” or “sorry, that’s not in the specs”) to focusing on doing the right thing for the organization.
What if You’re Developing Software for External Consumers?
If the end users for your IT project are not people who work within your organization, you probably won’t want to rush the product into their hands. Instead, you should get your Quality Assurance people involved as early in the process as possible so that they can act as the end user surrogates. It may also be possible to do a “beta test” with selected end users for mutual benefit.
Conclusion
Helping your IT project succeed means making sure that the project that is being built will meet both the project specs and the real needs of the people who will use it. To do this you should include representatives of the end users on the project team, and then give them something to “play with” as soon as possible. Real needs trump specs.
Surprisingly, although this technique sounds like it will take longer, in practice I have found that it typically results in getting a meaningful solution to a user problem sooner. Why? Because you avoid going all the way to the end of the project, deciding that it’s wrong and then creating another project to make it right. Adjusting mid-stream lets you get it right the first time.
Watch for my next article, where I’ll be discussing a closely related topic: including time in your project plan for iterations and changes.
About Ken Norland
As a strategic leader in IT with many years of experience, Ken has led significant teams in professional services, product development and large program/project management. His ability to see and act on both the big picture and on tactical needs is rare and valued.
Ken has participated in several mergers and acquisitions; managed large, multinational development teams; led Enterprise Architecture efforts; and provided strategy for multiple companies and technologies.
About CIO Professional Services
CIO Professional Services LLC is a top-rated IT (Information Technology) consulting firm, based in the San Francisco Bay Area, specializing in strategic IT consulting and business / IT alignment. Companies come to us seeking assistance with their information technology strategy as well as to source interim CIO / CTO employees or fractional CIO / CTOs.
