I received an e-mail recently from someone that had taken a requirements course with me in the past. He was looking for wording to use for an RFP to bring in some external consultant to wrangle the requirements of one of their systems together. Expectations were in the 2-6 person-months range, likely a contract that would entice some of the big players to bid on the proposal. I had no suggestions that directly addressed his needs, but did have some thoughts on what could be more effective.
In working with many organizations, I have heard far more tales of woe than success stories around bringing in consulting firms to take on a strategic initiative. There are usually cost overruns, often time delays, and the results can sometimes be less than stellar. The consulting firm does well with the engagement, as they have billed for their time and often reap a healthy profit. The outcome for a requirements engagement such as this will often leave the client to complete the project, based on information that they had little participation in building. The risk of successful completion with a good spec that someone else built can be as high as with a so-so spec that was put together by the team itself.
For a lot of shops, an alternative to outsourcing a key component of a major project would be to insource it.
Particularly with this group, there have been a number from the team that have taken courses from me in the past: requirements, use cases, project management, inspections. Embedded within the team is plenty of base knowledge from which to work. They are working to extend an existing application, rather than starting from scratch on a greenfield implementation so domain knowledge exists within the team as well. To outsource the whole ball of wax, with its corresponding high costs, potential for time and cost overruns and departure of much of the insights behind decisions when the consultants leave, doesn’t make much sense in this case. And there are many cases such as this in the software industry
I suggested that leveraging their own resources, along with strong outside facilitation, makes more sense in every dimension. Overall costs would be reduced dramatically, as there would be far less of a learning curve (the people doing the work are already familiar with the domain), and those sometimes outrageous consultant fees would go from upwards of 6 months of effort down to a matter of a few weeks. Buy-in within the team would be significantly stronger, as the team itself would be developing the assets, would have ownership in those assets, which increases the likelihood that these assets would actually be used as a basis for the remainder of the implementation.
Perhaps most importantly, though, the team would gain expertise in performing this important work in the context of their own projects (rather than the sanitary classroom examples where they were first exposed to these strong practices), and they could wean themselves from dependence on outside help in the future.
Reduced risk, cost and effort, with certainly increased ownership of the product and likely increased quality, all while increasing the capabilities of the team itself. The result would almost certainly be a better solution than to lean on external consulting organizations to do the work, then disappear with the profits. – JB