Tuesday, November 04, 2003

High Tech Productivity Imperative

McKinsey Quarterly is raising the imperative need for improvements in high tech productivity in this article, “What high tech can learn from slow growth industries”. I think it is fantastic that widely read, broad spectrum publications such as McKinsey’s are prepared to talk about this. Software development needs to get more productive if it is to remain relevant in the 21st Century!

Even matching best practices across-the-board won’t lead to sustainable differentiation; high-tech companies must also strive for productivity breakthroughs. Of course, this is easier said than done. Often, a process innovation represents the sum of seemingly disconnected parts.

If I have an issue with this article, it is that it raises the right question but only skirts around the answer. It is all very well to suggest that managers in high tech development need to understand what drives their value chain and learn to manage and focus on what limits its productivity, but managers need solutions not just more to worry about. Readers of this site will be glad to hear that they can look to “Agile Management…” to supply those needed answers.

A key message from this piece is that process change to create superior productivity in software development must be seen as a company wide initiative and must be led from the top.

Furthermore, most high-tech companies value and reward technology innovations rather than business process improvements. When these companies do think about productivity, their efforts are typically scattered and deep in the organization. Disjointed programs probably can’t move the needle.

What is vital is a commitment from the top to view productivity as a strategic imperative and to realize the organization’s agreed-upon process priorities. Employees, motivated by reward and recognition systems, should understand and agree with the focus on productivity.

Monday, November 03, 2003

Chapter 2 - Management Accounting for Systems

Chapter 2 introduces many concepts which represent the foundation for the rest of the book. It is a difficult chapter. It starts by introducing the concept of Systems Thinking. This is not new to software, Jerry Weinberg first introduced it in Quality Software Management Volume 1. However, my treatment is simpler and more aligned with complex adaptive systems theory. I separate out desired adaptive behavior - working code - from emergent properties - such as documentation and bug reports. The diagrams map a system for software engineering into three basic areas - an input, an output and a system which converts input to output. Financial metrics for this are then introduced - investment (the value of the input), operating expense (the cost of operating the system), and throughput (the rate of value-added observed at the output).

These financial metrics are based on Throughput Accounting (TA), the management accounting technique developed for the Theory of Constraints. TA takes a global systems view of management accounting, as opposed to traditional cost accounting metrics developed from Taylor’s time-in-motion theories. Cost accounting measures locally and assumes that local optima results in a global optimum. The Theory of Constraints rejects this notion and TA was developed to replace cost accounting.

The Net Profit and Return on Investment (ROI) equations for TA are then introduced, followed by a discussion of the relative importance of the three main metrics, T, I and OE. This is based in arguments from Goldratt’s The Haystack Syndrome and Corbett’s Throughput Accounting. It shows that Throughput is most important, followed by Investment and then reflects that cost accounting focuses first on cost, Operating Expense, then on Investment (inventory) and lastly on Throughput (the rate of gross margin creation). The chapter concludes by observing that the TA focus on Throughput is aligned with the Lean Production principle of “focusing on value”.

Sunday, November 02, 2003

Programmers Abroad

McKinsey Quarterly correctly identifies, in “Programmers Abroad: a Primer on Offshore Software Development”, that there is a category of software development which is best done in the local market - projects which have high uncertainty in the user task flow, screen design and business rules. These projects require short iterations and customer intimacy. Projects best done locally with agile methods. Check out Exhibit 3 a 2x2 matrix which identifies 3 classes of software development which may be best outsourced offshore, whilst the fourth must remain on-shore, local and in-house.

Offshore partners may have difficulty maintaining application designs for projects such as e-commerce applications, which have short time frames or call for feedback from users. But once these projects enter the later stages of development, even they can benefit from outsourcing. A developer of business-to-business (B2B) software who regards speed to market as critical remarked, “With our new overseas operation, our team is working round the clock, and I now have access to a larger pool of IT resources than I did in the US alone.”

Tracking Value for Accurate Reporting

Mac Felsing, co-author of A Practical Guide to Feature Driven Development, explains that projects are more easily managed using self-generating metrics based on tracking the value created at fine-grained milestones. This is the first issue of the Process Perspectives newsletter, “The Hidden Costs of Application Development”. Mac reports that tracking fine-grained milestones improves the accuracy of reporting, eliminates noise in management metrics and eliminates wasted time and expense gathering project management data.