Lost in the Weeds
Some companies require up to 4 times the capital to reach the same place as a competitor. How can that be? The Silicon Valley way is to throw money at the problem (often by making expensive hires, for example), but is it the right solution to the right problem? For example both Zazzle and Café Press compete in the custom designed clothing area, but Zazzle, which raised $46M is behind the leadership position of Café Press which has raised $15.5M. Wouldn’t it be better to have an understanding of the drivers that will lead to the most rapid and efficient achievement of a goal, and execute those drivers efficiently? Unfortunately, too many companies have put in place development processes that slow down, rather than speed up, product creation. These companies are lost in the weeds of process. You have all seen the symptoms of these organizations with their endless phase reviews, PowerPoint presentation decks of sixty slides (thirty of which are in the appendix), long and large meetings in large conference rooms with unnecessary participants, pre-meetings and follow up meetings and yet slips in schedule still occur. More time is spent on creating the documentation for reviews and going over checklists than actual design work. More time is wasted preparing and formatting information for management than focused on moving the project forward. This situation is all too common and results in low morale, low productivity, and often missing the big picture such as the case with Zazzle and Café Press.
The potential impact of streamlining development is huge. The Global R&D spending of the 1000 largest corporations totals $384B and is growing at a rate (until recently) at 6.5% per year (Booz Allen Hamilton Global Innovation 1000 Study). If by simplifying processes and focusing on doing the right things, a modest reduction in waste would bring staggering savings in absolute dollars. Furthermore, at the company level, this can be the difference between winning and losing. For a startup, it can mean the difference between survival or cash-out. For more established companies, it can mean the difference between being first or second to market. In this economy, you can’t afford the wasted expense. In this competitive climate, you can’t afford being late to market.
Given that the natural tendency is more bureaucracy over time and organizations by their very nature become more risk averse as they age, what can be done about this chronic problem? There are two approaches: Bottom up – starting with nothing, and Top down – paring down with what you have.
Consider the analog to zero base budgeting – zero base process. Start with a clean sheet and then describe the few essential phases of design: Definition, Design, Realization, Test & Release. For each one of those phases define a key deliverable (or two) and determine if a management review is required. That is the zero base process. In the case of each deliverable, define the minimum standard for that deliverable – the so called core content that addresses the central questions that the deliverable addresses. Start at the most basic level and omit the rest. Over time add more if required based on rigorous analysis of the degree additional process would help to get things done better and faster. We have written about this approach and called it “Goldilocks and the Three Bears.” Also, Agile methods can be used that break tasks down in to small rapid iterations performed by a small software team. Each iteration leads through the normal development cycles above, but in a four week period.
If this zero base process approach is too radical for you, you might want to consider a top down approach, which is where you eliminate non valued added steps – documents, deliverables, checklists, management reviews and also lean down the size of work that is generated just for the sake of management. Start with a meeting and deliverable inventory. For a typical effort, list every type of meeting the team members participate in (both for the project and non-project meetings). Rank order the importance of these meetings, draw a line, and stop holding or going to meetings below the line. Sometimes you will need to get management approval to cut, but demonstrate why this does not add value, and they will be receptive. Do the same process with the deliverables too. Critically review all documents that are for management (versus those for upstream or downstream organizations), rank them, draw a line and eliminate those below the line. Once that is done, lean down the content too – just deliver the essential core documentation.
Regardless of which approach you use, zero base process or top down, carefully review any standing meetings. Weekly (or other regular periodic meetings) are vast time sinks and should be cut to the bone. There is no reason to have any more than 1 standing meeting per week involving the entire team with any project. Supplement the need for rapid and regular communication with instant messaging for quickly called, quickly held meetings. Also, a best practice that we find helpful for ensuring that issues do get communicated and resolved quickly, with fewer management meetings is the “Out of Bounds” review process. By defining and documenting clear boundary conditions, there is no need for management oversight and constant reporting that everything is OK. However, if the team detects that they will cross a boundary, and may fail to meet performance, quality, or schedule goals, they hold an ad hoc Out of Bounds meeting (or resolve it by sending an email with recommendations).
Predictive Metrics are important in the simplification process. We like to manage change by measuring behavior. In that regard, how does one ensure that we are really walking the walk with respect to the new process? In larger organizations where there are ten or more programs going on at any one time, you can measure the percent of programs that are following the newly simplified process. Because this transition cannot happen overnight, a metric target should be devised to estimate how fast we will get to 100% conversion, and then you track this every week or so. Besides measuring change in the process, a simple predictive metric can be put in place to gauge the speed of the project. We call this “Schedule Prediction Accuracy” and it is a line graph that plots the estimated release date over time. An ideal program is a flat line, since the predicted release date does not change when the schedule is periodically updated. This one simple graph can displace the complicated dashboards and other cumbersome metrics systems that are often deployed in development organizations.
Regardless of which path you choose to take, there is no better time than the present to look critically at the development process and eliminate the waste. There is much less risk than you imagine, and much to gain in labor savings and morale.