In my earlier blog, entitled The Investment, I talked about the importance of maintaining realistic expectations for the costs and efforts involved in custom software, making the business case, and avoiding the knee-jerk reaction. Here I will outline a related topic. One of the ways in which businesspeople can avoid misalignments in their expectations is to take ownership of their own projects.
Businesspeople unfamiliar with a software development cycle will often limit their thinking to the “idea” stage. Numerous times over the last few years I have been approached by people who have truly excellent, highly innovative ideas. They may even have fleshed out much of the business side of the equation – prospective customers, business partners, products, services, etc. However, their concepts about the software application remain very nebulous.
A similar issue arises, particularly in small businesses, where there is a major process that runs inefficiently. The business owners may be looking for software to improve the situation, but they don’t really know what that would look like. These people are very vulnerable, and may wind up spending a great deal of money on systems that really don’t help them much.
One of the things we do at Russell Kennedy Partners is to get the clients involved in the actual design of their applications. We are not asking them to plan the actual software, but rather to identify the major functional and process components of what they want to build. When they do this exercise, they often find it to be both eye-opening and empowering: eye-opening, because they come to realize just how many moving parts are involved; and empowering, because they now have the ability to take control of their system, to make their own informed decisions and tradeoffs.
This exercise can take a number of forms. We sometimes talk with the client about building the major “use cases.” Use case is a technical term, but you can think of it simply as a typical path a user would take through the application. For example, a new (unregistered) user comes to your website, and wants to register as a user, or buy a product in your catalogue, or buy a product and register during the purchase. What are the pages or screens the user will go through, and what is the functionality and flow? We sometimes encourage clients to build their own wireframes, which are outlines of the components (such as fields and buttons) on a screen or webpage. Sometimes clients at first come back with only a few of the wireframes that are needed, but then, with a little prodding and encouragement, they step up and deliver a complete set.
When the purpose of the software is to automate a more extensive process, sometimes we start with a little education in terms of what process automation/workflow is and what it can do. Then we encourage the clients to define and outline the process: the specific steps, the conditions for completion or failure, the times allotted, the escalations, and so on. At that point they must examine both what they do today, and what would work better for them tomorrow, with the benefit of structure and automation. I recall one client who initially didn’t understand workflow. However, as they say, the light bulb went on. Then, with a little prompting, she used the graphics in Excel (something familiar to her), to diagram out the entire process as she wanted it to work. This also saved her money (and possibly time as well), because she did what would have otherwise been done by software designers pestering her with lots of questions.
These are the examples of ways you can take ownership of your project. The downside of doing so is that your expectations may deflate somewhat. You may realize that you will be paying more and doing more to get where you want to go. However, the upside is that you will dig into your project and own it. You will make the major decisions, though good guidance will always be available if you work with a good professional team. You will have a grasp of all the interlocking pieces of the system. If a bug surfaces later, you will be able to troubleshoot enough to get a quick response from your team, since you will know exactly how things should work. Finally, if things don’t work out with your team, or the team has only come in as early stage tech advisors, you will be much closer to having a working requirements document that you can bid out to other companies.
Copyright © 2012 Patrick D. Russell