One of the most challenging aspects of any large endeavor is to manage the processes, people, resources. and commitments associated with portfolios of active and candidate new product development programs. I developed the below graphic to provide an overview of a possible set of data relationships for this situation. It is intended to serve as one view of what these relationships might consist of at a very high level; like any such view, it emphasizes some aspects of the situation, and ignores others. Read more »

Sometimes you get the bear, and sometimes the bear gets you. When we see an inspiring wildlife picture of a bear with a salmon in it's mouth, it's very easy for some of us to relate to the bear. This is the mental model we have in our heads of our role in our environment. But often, we're the salmon, not the bear, and when that happens, the swim doesn't quite seem like it was worth it.

There are several lessons we've all heard countless times, and that most of us intuitively understand. In work settings, I routinely try to practice these lessons. But in my personal life, I sometimes find how easy it is to try to take shortcuts... and when I do, I find I re-learn again why key practices are so important, as I have over the last several months: Read more »

The Software Program Manager's Network (SPMN) was established in 1992 by the Navy to identify proven industry and government software best practices and convey these practices to program managers of large-scale DoD system acquisition programs. By sharing and applying such "in the trenches" experience, the SPMN enabled these program managers to achieve improved program success and deliver quality systems on schedule and on budget. 

The SPMN 16 Critical Software Practices target underlying cost and schedule drivers that have caused many software-intensive programs to be delivered over budget, behind schedule and with significant performance shortfalls. While these practices were originally identified for software-intensive systems, nearly all are generally applicable to any large-scale engineering effort.  The SPMN's collective lessons learned provide additional relevant insights from their assessments that can servive as meaningful examples for others in their own benchmarking, training, and planning activities. Read more »

When a highly anticipated and popular new product like Windows Vista is released, over the course of it's first few months in the field, tens of millions of users can rapidly migrate to it and begin to use it. Their 'first impressions' will have a profound impact on the future success of the product.

When such a products are large and complex - and especially when they are software-intensive - there are three simultaneous trends underway during this period. First, many on the team which has been working on the product while under development will begin to move to new assignments, or take on new features for future releases or products (especially the most highly rated members of the team). Second, the number of hours of execution per day that the product's code base is being subjected to grows exponentially, thus increasing the likelihood that latent problems will be uncovered. Third, your call center personnel (because of the need to spin up large numbers of new people to provide support) will likely have less knowledge and experience than at any other time in the product's lifecycle. This is a knowledge management challenge for the development and support team, to say the least, as well as a stress on the maturity of issue management processes. Read more »

I've been working for the past few weeks on several features of this web site that I felt were important:

• The capability to aggregate RSS data from partner blogs and provide it on various views
• The capability to provide visibility of content which is still under development when desired
• The capability to subscribe to content and get email notification when it has changed

Such statements can form the start of functional requirements, but for me on this site, as in so many other situations, it's often first more fruitful to explore what's possible through prototyping and experimentation, before spending too much time trying to get the lower-level requirements right. This is particularly the case when the technologies you choose to use are unfamilar, evolving, or immature. In the case of the above capabilities, some required support from other open-source authors, some required changes on my web site host, and some were able to be done locally.  Read more »