TO: Steve, Kim, Murray, Catherine, Jen, Bob
FROM: Kurt
SUBJECT: New sales tracking application
Hi all
We’re about to start building new version of our sales-tracking system. I’d like to get you all involved in the design, so we make sure that we wind up with something that works for everyone.
Regards
Kurt
———————————
TO: Kurt
FROM: Cath
SUBJECT: Re: New sales tracking application
Hi Kurt
Glad to hear that this application is going to be redeveloped. My sales guys find the current system really hard to use. Please involve them in the design process.
Thanks
Cath
———————————
TO: Kurt
FROM: Bob
SUBJECT: Re: New sales tracking application
Hi Kurt
It’s imperative that the new system has good management reporting so we can forecast accurately!
Cheers
Bob
———————————
TO: Bob
FROM: Kurt
SUBJECT: Re: New sales tracking application
Hi Bob
Understood. Could you draw me picture of the reports you want to see? Without having examples of what you’re after it’s difficult to design the reports.
Cheers
Kurt
Application developers have tricky job. Ensuring sufficient input from the users of the application is critical. But sometimes users don’t know what to ask for. They are used to things being done certain way because that’s how they’ve always been done, and they can’t always see alternatives.
Building new application is great opportunity to examine existing business processes and review their efficiency. But therein lies problem. There’s often knowledge gap and communication breakdown between users and application designers. They simply don’t talk the same language and don’t have the same understandings of the business.
Users are likely to know the nuts-and-bolts of existing business processes more thoroughly than application developers. But they don’t know what is technically possible. So what they ask for is often not what they should (or could) be asking for.
Application developers, on the other hand, know what’s technically possible. But they are often led by desire to please users and give them what they ask for rather than taking step back, challenging users to review existing business processes and helping them look for ways to improve them. All too often they’re also too removed from the day-to-day operations to be able to judge good processes from bad ones.
As result, applications get built that embed inefficient business processes, and the opportunity to create efficiencies through new system is lost.
So what can be done? The secret is to ensure that the project team responsible for designing and building new application is proper team – with representatives from all the affected areas of the business not just from IT.
It’ll do no harm for members of your sales or marketing teams to gain some exposure to technology by working with the tech guys. And it’ll do your tech team power of good to work more closely with other staff and get better sense of their processes and priorities.
The team needs to throw out any pre-conceptions about what they’re trying to do, and start right at the beginning – with mission statement. What is the project trying to accomplish? What are the critical business issues that it is trying to address? What are the limiting factors (time, money, staff etc)? And, importantly, what would be successful outcome? The latter is essential if you are to clearly understand project’s return on investment.
Even in small companies it’s good discipline for the project team to produce this high-level document and have it reviewed by senior management. That will help ensure that the project aligns with the company’s overall strategy.
The mission statement should be reviewed regularly and any variance to the initial statement noted and communicated to all affected parties. That way, sensible decisions can be made about the project as the scope and goals are refined over time.
The project team should also build thorough process map. Not only those pro-cesses the application itself encapsulates, but all the processes involved in interacting with the proposed application too. What data goes into it (inputs) and what comes out (outputs such as reports, connections to other systems etc)? Where does that data come from and where does it go?
With clear map of existing processes, the team can review each process and step to gain clearer picture of what processes the new application ought to provide, and what business benefits it can deliver.
Although it seems onerous this disciplined approach will help to resolve the yawning chasm between users and the application developers.
Mark Evans runs Techtelligence and is director of Sway.Tech, marketing, communications and strategy consultancy for hi-tech companies. [email protected]
