In my last blog post, I discussed how including larger factors of safety in our requirements estimation and design might help give business analysts the breathing room they need when unexpected scope/features pop up in a project. Another interesting aspect of engineering design that could be incorporated in some way into software development is called “front-end engineering design.”
For some engineering consultants and contractors, before they put out a big bid on a project, they will do a very minimal amount of engineering work to help with their materials, engineering and construction cost estimates. They call this front-end engineering design. The engineers are not trying to satisfy all the design requirements, constraints etc. in this phase, but rather do enough design to have a good estimate to bid from. There could definitely be an analogy in the software consulting world for using something similar to help estimate projects. However, this idea can also inform customers in how they plan for projects in the software development lifecycle.
Some companies in software development actually use their requirements process for this purpose. They gather requirements, write the BRD, have it sized and then determine what can be implemented within the given budget. However, even before you get into actual requirements, at the business strategy and enterprise architecture level, you can do some software “front-end engineering design.” This can be accomplished by putting in a minimal amount of requirements effort to determine the business problems and business objectives along with the various product concepts and features that would meet the business objectives before ever creating the actual project to go and elicit the requirements.
I imagine most companies do this in one way or another (through cost-benefit analysis, business case or something similar); that’s how they determine which projects to go forward with. But, on most of the projects I’ve seen, if they do this, the results do not trickle down to inform the requirements phase of the project. Business analysts and product managers are therefore left to go “rediscover” the business problems, objectives and features. With front-end engineering design, once the bid is accepted, the engineers don’t just scrap their initial engineering work and start over; they build off of it and refine it. The Project Management Body of Knowledge encourages this in how project management and individual projects tie back to business value via program management, portfolio management and business strategy.
To that end, it would also be beneficial for all of software development to use consistent visual models or templates from business strategy down through requirements management. That way, when a business analyst starts on the project, if using RML, there is already a Business Objectives Model and Feature Tree to work from and the BA can jump right into defining current and as-is processes as well as detailed functional requirements for the already agreed upon features. Also, if the use of visual models or specific templates is percolated throughout the entire organization, you don’t have a cost-benefit analysis at the business strategy level and a Business Objectives Model in the product/requirements management level. You would be able to save time and effort in the requirements gathering/documentation phase by having some information for the project to work off of and refine.
So, what do you think? Do these engineering principles apply to software development? Why or why not?
