The research occurred at a medium-sized development arm of GridCo1, a large multi-
national provider of power and smart-grid solutions. The company produces a product ecosystem of utility meters, network storage and routing components, and command- and-control software (“GridWare”) that must operate not only on legacy systems, but interoperate with competitor systems and meters, and adhere to common standards using a variety of communication media (e.g., Internet, radio frequency, power-line carrier and cellular). The development arm of GridCo is composed of several hundreds of people. GridCo builds hardware, firmware, and administrative control software via a hybrid process of plan-based and flexible development, using more than 35 small software development teams at multiple locations in the U.S., an offshore captive in India, as well as outsourced development providers.
For several reasons, the industry is dominated by a handful of incumbents (including GridCo). Because customers tend to be large utility providers, the potential market is limited, and there is thus strong competition for a relatively small number of customers. Although GridWare meets the definition of package software as outlined in this dissertation, GridCo both does and does not exhibit the attributes Sawyer (2000) ascribes to organizations developing packaged software (See Chapter 9).
This research is primarily concerned with a single release cycle of the GridWare command-and-control system during 2013 that was planned to last 36 weeks. We observed meetings from related projects as part of data collection in order to build a richer picture of the release cycle and to observe behaviors similar to those employed
Stage Milestone Stage Description Contextual Application
Discover NPD-0
Start
Not technically part of the defined and gated NPD process, but listed in the company’s documentation. Documentation states, “Ideas are captured and scored using a
standardized, cross- functional metric.”
No formal ranking or filter processes at this stage were observed. Methods of weighting and ranking other than contractual demands (sometimes with financial penalties) were not
referenced by participants. Data imply customer meetings, contracts, and internal R&D are filtered through product area managers at this stage.
Scope NPD-1
Scope Ask Sprint 1/18
The scope for the next cycle is considered, and sized (roughly estimated). High- level scope for the cycle is communicated to
executives and project leaders.
Backlog list is almost always oversubscribed, and exists only for current cycle. Development work commenced before scope document complete. Formal scope ask delivered after cycle already started.
Commit NPD-2
Scope Commit Sprint 3/18
Scope is determined feasible and approved. A particular scope is
committed to for the cycle. Development formally begins. Change control implemented for further scope/budget changes.
Software development has already been occurring throughout the cycle. Scope commit actually occurred in sprint 9, mid-way through the cycle.
Develop NPD-5
Feature Complete Sprint 14/18
Actual development should be completed by this stage. The product is ready for verification, testing.
Some few items remained, and were continued to be worked, when this stage was to begin. Verify NPD-6 Testing Complete Sprint 18/18 Testing is complete.
but which we could not observe directly for timing reasons. Development of the GridWare system for the observed release cycle depended on related hardware and firmware projects, which increased both the volatility and complexity of the observed requirements.
GridCo uses a series of stage gates that overlay a common technology NPD process. Ostensibly, “gates” describe “go/no-go” decision points; while this was allegedly true for some gates at GridCo, more than one participant intimated that inertia as well as market and contractual demands made continuation of the release cycle all but certain. Indeed, GridCo’s NPD overview document read, “The stages are ‘soft’ meaning that work in a subsequent stage can start before all the deliverables of a prior stage are complete.” So in practice, these gates functioned more like milestones. Table 7–1 lists the stages, the end-of-stage milestones, a brief description of each stage, and brief comments about how the stage was implemented at GridCo. These are marked with labels that correspond to stages of GridCo’s NPD process.
Observant readers may note that stages in the above table seemingly skip over NPD-3 and NPD-4. Although GridCo utilizes these interim stages for hardware processes, they are not present in software processes. This NPD process is universally mandated at GridCo.
Perhaps the most interesting point regarding the application of the stated NPD process, was that not only did development work commence before scope was finalized, it commenced before the high-level scope for the release was trimmed to an accomplishable size, with nothing formally more concrete than knowing of some contractual obligations that would certainly be part of the final scope. The initial NPD-1
date was delayed from February 10th to March 10th (and eventually delivered March 12th), two sprints into the 18-sprint project.
Similarly, the deliverable scope for the release cycle was not committed to until the cycle was half over. This NPD-2 deliverable was a formal event that involved multiple layers of local review as well as presentation to an executive global approval board. The project manager faced internal pressure from his superiors to move the NPD-2 (scope commit) date earlier in the release cycle. Several participants indicated the NPD-2 date had a tendency to move later in the cycle than they would like, but provided no argument for having it earlier other than doing so would be less embarrassing to explain to the executive global approval board. (The NPD-2 review, per the global process, includes a budget and resources request to accomplish the described scope, although most of those personnel resources have already been utilized.)
Indeed, a “late” NPD-2 benefited the cycle as scope was flexible up to that time; any scope changes following NPD-2 approval required change control and executive oversight. This permitted multiple scope changes early in the cycle resulting not only from identity and complexity reasons, but also due to unpreparedness of bottle-necked preliminary work.
Thus, it is important to understand that while employees at GridCo considered this release cycle (and previous cycles) a success, the scope documents against which cycles were evaluated were not set until the middle of the cycle when many uncertainties have already been resolved.