The first time I participated in a system design class, it was for Microsoft Access 95. Interestingly, something I learned from that class has stayed with me over the ensuing twenty years:
before you start designing your system, know what you need to get out of it.
It doesn’t sound revolutionary at all, right? Unfortunately, this isn’t how many firms go about their process of designing technology projects. For BD tech in particular?—?because it is not necessarily something your IT team will use on a regular basis?—?it is common for the steps to be more along the lines of…
- Schedule demos of the software.
- Write an RFP full of feature/function specifications.
- Receive multiple proposals, and sort them by price.
- Pick a vendor.
- Start your implementation with a business requirements session
Does anyone see the critical problem with this approach? If you are not defining your requirements until you’re in the implementation phase of your project, you’re leaving yourself open to significant misunderstandings among your (internal) clients, your project team, and your vendor. You’re not figuring out what you need to get out of the system (the answers) before you start.
Instead, take advantage of the life lesson above, and take another approach.
Start your project by figuring out where you need to end.
This sounds simple, but it really isn’t. A small example:
Many years ago, I worked with a company who called in with a request for a report. The client’s project manager indicated they needed a PDF report that would show them business development activities by user and date within a business segment. The project manager had received the project and description from a segment leader, and it was not feasible for the consultants to work with those end users.
The development team went ahead and built the report to specifications, but in the end, it didn’t actually solve the segment leader’s business problem. Why not?
It didn’t actually answer the question that she wanted to ask.
Instead of a report about activities, the leaders really needed a report about the firm’s users and what they were doing. It sounds like a fine line and maybe an insignificant difference, but it (as is always the case) it was anything but insignificant. The project manager was frustrated, the consulting team was defensive, and the segment leaders were impatient.
This could have been easily solved by a business requirements session?—?including something as basic as drawing out the reports?—?before development began.
In this case, had the firm taken the segment leaders through a thorough business requirements session, they might have ended up with a needs statement more along the lines of
I need (the Answer): A report that shows all of my team members and each of their business development activities within the last quarter so that I know who is doing what.
Do you see how different that is? Among other things, you’re asking to report on what isn’t there?—?things that aren’t in the database. In this case, the segment leaders wanted to see a zero next to the names of the individuals who had not, in fact, created any business development activities in the last quarter.
This is the first in a series. Check back for a examples of how you might facilitate a conversation to truly ensure your BD tech project is answering the right questions for your firm. Please contact me if you’d like assistance figuring out the right questions for your answers. I can be reached at firstname.lastname@example.org.