As a customer, how can you get the most out of your consultants? As a consultant, how can you deliver what your customers really want? I have been on both sides of this relationship and experienced both successful and unsuccessful results. In this post, I will go through the typical aspects of these types of relationships and identify action items that I have used to forge effective and lasting customer consultant relationships for both parties.
The Typical Process
The process I am about to outline is not the process for all software consulting firms. However I have seen this happen frequently and have run into this situation myself as a client and as a consultant.
The customer comes up with a general idea of an application that would bring value to a group of people. Then he/she finds a firm that has experience building software and hires them to build the application.
The consulting firm takes a week or so to build a master plan based off of the customers ideas and shares it with the customer. Once the customer okays the plan, the consulting firm starts building the application. Since applications are very complex, the firm builds the application assuming basic details like user flow, page layouts, etc.
After the firm has done a week or two of work, the customer has had more time to think about how their app should work. When they see what the firm has created so far, it doesn't quite match up with what the customer has envisioned in their head. So they give the consulting firm more specific information about their application. With the new specific information, the consulting firm fixes their improper guesses and adjusts their code to line up with the new information the customer has provided. The fixes took time away from development, so now the project is a little rushed.
A couple weeks or months pass, and customer has come up with new ideas that will add tons of value to the application. So they share these ideas with their consulting firm. The consulting firm informs the customer that making these changes will add significantly to the development time because the system wasn't designed to support these new features. The customer is not happy to hear this, but this new idea is really important, so it has to go in. Now the project is over budget, over time, and rushed because the consulting firm has to change the structure of the application to accommodate the new idea.
This process occurs because the business requirements of a project evolve over time as the customer learns what features add value to the application. In this scenario, whenever a business requirement evolves, the consulting firm has to backpedal to add it into the system.
How To Avoid Major Delays
A major fear customers have is that the project will take longer to develop than the original estimate suggested. At the same time, one of the hardest things to do as a consultant is to estimate how long a piece of software will take to develop. To minimize the variance in estimations, it is imperative that the development schedule be broken down into a prioritized series of fully-thought out minimum marketable features (MMF). Also, initially only the most important MMFs should be estimated and built out to form a minimum viable product (MVP). Additional features can be added on top of the app once market feedback has come in from the MVP.
A MMF is defined as the smallest group of functionality that adds market value to an application. When a project's functionality gets broken down into MMFs, the project gets built in small working slices. Each slice can be demoed once it is done, and feedback is easier to give when the customer can play with a demo.
A MVP is defined as the smallest group of MMFs that allow the application to be deployed. As the time and scope of a project gets larger, so does the amount of complexity. No matter how experienced a consultant is, he/she won't be able to clearly picture what the application will look like until relevant parts of it get developed. Therefore, it gets harder to estimate features as the project specs list get larger.
Additionally, a tight feedback loop should be established. The customer's specialty is understanding the business requirements and the consultant's specialty is implementing functionality. Since the business requirements change over time, the customer and consultant have to work very closely to ensure that the consultant is implementing features that fulfill the current business requirements.
Customer Action Items
Demand that your software gets built in short release cycles
You are more capable of giving quality feedback when you can play with a demo of your software (plus playing with your software is fun). Additionally, your consultants will spend less time guessing and more time developing when you can give great feedback every week.
Break apart your idea into minimum marketable features
When you create a MMF, it is easier to drill down into the specifics of what you want out of a certain aspect of your application. Additionally, it makes it easy for your contractors to build in short release cycles when they can simply implement a handful of MMFs per cycle.
Initially, only build enough features to create a minimum viable product
You won't know what actually brings value to your market until you can release something. When you put a MVP in a client's hands, they will be capable of giving you extremely valuable feedback that you couldn't get otherwise.
Be available all workday long for questions that your consultants come up with
It is more cost effective for you to answer questions that your consultants have, rather than them guessing an answer and you having to correct their mistake down the line.
Consultant Action Items
Build software in short release cycles
Building software this way creates a tight feedback loop with your customer. Also, it pushes you to build an extensible architecture that can deliver business value amidst changing business requirements.
Persuade your customer to break up their idea into minimum marketable features
If they don't provide a MMF with specific acceptance criteria, then it will be extremely difficult for you to deliver value to them (unless you can read minds).
Don't estimate features that won't get implemented in the upcoming release cycle
No matter how smart you are today, you will always be smarter tomorrow. So don't waste your time estimating a feature that won't get implemented in the near future. Your estimation will change as you learn more about how the system should work.
Communicate with your client on a daily basis
Even if you only communicate with your client 5 minutes a day (excluding weekly product demos/meetings), your customer will feel in control of their project if he/she knows what is happening every day. Additionally, the more feedback you get from the customer, the less guessing/mind-reading you have to do.
Conclusion
It is both the customer's and the consultant's responsibility to forge an effective relationship. Both parties should work together with an understanding that the business requirements WILL evolve. If they follow the action items that I outlined, their relationship will be extremely effective at building projects that produce value.
