Is it possible to shift your development group into a consulting attitude?

Not like the big behemoth consulting companies do, but like the little ones—the ones that can conceive of something smaller than a man-year.

And if you could, should you want to?

Consider this—a worst case software development scenario.

A software development group is charged with creating a software product or component. It could be a new product or a new feature release of an existing product. Requirements are defined well enough that the group understands what they need to do. They agree to the release date.

And then…they miss the deadline. Release content is stripped out. New release date is agreed. And then…they miss the release deadline again. More personnel are thrown at the activity or more content is stripped out. New release date is agreed. And still the deadline is missed.

Parallel to this, customers are clamoring for the new product or functionality. Sales can’t close deals. The window of opportunity in the marketplace is starting to close.

There are books—tomes even—that detail how to avoid this problem in the first place—and bail yourself out of it in the second. Given the number of remedies offered up, why does the problem recur?

We just witnessed it in all its glory as our federal government tried to go live with the health insurance exchange. With all of their processes, procedures, regulations and oversight, how could that happen?

Compare with this—what would happen if consultants were doing the work.

Good consulting groups structure their projects so that all of the risks are abated.

First, all requirements that are foundational in nature are identified up front.

Second, any technical challenges are subjected to proof-of-concept. Third, releases are defined so that content comes out incrementally. This allows for course corrections along the way.

Finally, consulting groups typically estimate at a very detailed level. This provides a level of transparency most software development groups would never dream of. They can rapidly detect where work is exceeding estimates—and then determine why.

In the case of the federal health insurance exchange, it appears that critical application interfaces (APIs) were not fully defined until extremely late in the project. In a system that spans various state governments, federal government agencies, insurance companies and components, this is a foundational requirement that should have been done before Development Day 1.

Similarly, exchanging information is one of the highest risk areas for a project of this nature. It should have been subjected to proof-of-concept level development at the beginning. And yet we heard that end-to-end testing didn’t start until about a month before the scheduled unveiling.

There are other errors that are easy to spot.

A client who is price sensitive—as opposed to our federal government with its deep pockets funded by our tax dollars—would have been watching the project like a hawk. And demanding incremental releases with every payment.

You can switch your group over to a consulting model.

Step one is starting every new project or release with a discovery phase. It should be short—in proportion with the size of the project. Using 10% of overall development budget as a guideline will serve you well.

Discovery includes nailing down every foundational requirement. Does it or doesn’t it have a mobile interface? Is it or isn’t it cross-platform? What are the major use cases or user stories? What are the major functionalities behind the scenes?

Subject everything that is unknown or risky to proof of concept. For instance, if you’re planning to use a third party application or third party controls, test them out. Can they actually do the most complex tasks you have earmarked for them? Can you make key interface points work as planned? Can your proposed systems handle the load and performance requirements?

When discovery is complete, estimate all of the work. Demand high confidence on well-defined tasks that are scheduled for early development. Allow looser estimates on work that is scheduled farther out.

Then schedule your incremental releases with approximate content. Content can be shifted between releases as you move through the project.

Finally, set up a way to track estimates versus actual at a detailed level.

With these things in place, you shift into consulting group mode. You have high transparency—which leads to far earlier problem detection remediation.

If you make the switch or are wondering how to do it, we would love to hear from you. We might even let you use our estimating and tracking tool on a trial basis so you can quickly get up to speed.