Get Users Involved As Early As Possible
July 15, 2019PAST PATTERNS OF SOFTWARE DEVELOPMENT involved getting user requirements and then going off to do the coding and testing under a veil of great secrecy. After all, the users wouldn’t understand what we were doing anyway, right? At the end of the project, our magician’s magic cloth was whisked away and the user was expected to “ooh” and “ahh” at the brilliance of what we had produced. However, all too frequently the reaction was, “Well, I know you went to a lot of work, but what I really wanted was….”
Today, the secret to project success is to involve the users almost as soon as there is anything visible to show them. How much better it is to find out that there are problems with what we are developing early on, rather than after the project is complete!
Costs for changes become increasingly high the further along we are on the project schedule timeline. The time to recode, retest, and rework the immediate software, as well as to test integration with all the peripheral code involved, can delay the project substantially. And both time and cost baselines are jeopardized if a change is so major that it has to go through a lengthy Change Control Board process for approval.
Programming decisions over very minor issues, which make perfect sense to the software developer and the project manager, may create chaos back at the workstation when the software goes into use.
I know of a large training company that spent $5 million redesigning its ordering software. Previously, the item numbers matched the product being ordered in a logical way. For example, 4125 might be a student manual, 4225 was the accompanying student exercise disk, 4325 could represent the instructor manual, 4425 was the course outline for marketing purposes, and so on. You could order all the items in the 4×25 series on the same screen.
Each day, administrative coordinators in 140 locations around the world ordered the same kinds of materials over and over and soon memorized the item numbers. Once you knew the number for a student manual, you could immediately key in the numbers for the other items without looking them up, and ordering went quickly.
In the redesign, somehow the project team forgot to consider the way the ordering process was used by the real people doing it. Under the new design, there was no logical relationship between items. Item 6358 might be the same student manual that once was 4125, the accompanying student exercise disk was now 8872, and the instructor manual for the same class was 3392.
Not only did the user have to look up each item and try to “forget” the old numbers and system, but also each type of item was now on a separate page.
Administrative coordinators were furious. Ordering slowed to a crawl. The project far exceeded its time and cost baselines.
As a project manager, you should get the users talking to the software developers early and often.
This article first appeared in the book – 97 Things Every Project Manager Should Know and has been reproduced here under the Creative Commons – Attribution 3.0 license.
