Unmanaged fuzzy-front-end
/Manage the fuzzy front end
What is wanted versus what can be delivered? A failure to reconcile.
Rarely are engineering resources involved in the critical step of reconciling what is wanted with what can be delivered. The Marketing (or product) Requirements Document (MRD or PRD) is written and basically "tossed over the wall" to Engineering, who also typically ignores what they are not interested in, or don't want to do, or don't have the resources to do... and at the end of the day the resulting product is a function of what can be done versus what is really needed (by the customer).
Aligning the work effort to deliver the product that has been defined with the available resources is, in most cases, a missing step. Few want to deal with the problem that this "information" might cause!
In many cases the front end of development is identified as a problem (i.e. takes too long and produces poor results), but not fixed. Why, given the compelling business reasons that cutting 50-100% off of overall cycle time could have? First, it is a question of ownership. Who owns this front-end process, marketing or engineering? When two people own anything, no one owns it in practice.
Second, and more common from our experience is the lack of dedicated resources, because the resources that are needed for the FFE Project are stuck on the previous late development project and so on, the cycle just gets worse as more projects are added to the portfolio. In some cases we have seen managers "not fix" the problem since it provides a great excuse for poor performance later on... "we tried the best we could with what we had..." I don't think this is a conscious decision on their part, but in the end this is what is happening.
The biggest problem with poor FFE management is that the wrong product can be defined and the critical step of reconciling what is wanted with what can be doneis missed (i.e. in the white space between marketing and engineering teams). Yet, it is normal for the first-customer-chip (FCS) date to remain fixed even though the front end work was delayed. In the end, the engineering team has to "eat it," which further compromises the product later on through trade-offs made to meet the "aggressive" target date.
Properly managed fuzzy-front-endsyield these results (composite example from multiple clients):
We are managing it, rather than letting it “self-manage”
We've put a “refreshed” schedule to it -- are driving faster cycle time
FFE schedule will evolve into the full program schedule to FCS, first time we've had an integrated end-to-end schedule of the program
Better quality information with which to make decisions & commitments
We have a transparent process for requirements prioritization & reconciliation: with customers and between engineering & marketing
A way to recognize "constraints," to set proper expectations of what we can actual do within the time frame given our existing resource constraints
A link back to our portfolio prioritization system