English is a complex human creation, and it is as quirky as those of us who speak it. We expect certain structural attributes: symmetry, regularity, consistency, and logical construction of words and phrases. In general, our language delivers well on these features, but occasionally, or even frequently, quirks surface. A whirlwind tour through some counterintuitive usages illustrates this point.
IBM’s broad industry experience and deep internal know-how point to three key principles to deliver sustained measureable improvements in software business outcomes with higher confidence: Read the rest of this entry »
Most software projects require a complex web of sequential and parallel steps to achieve success. As the scale increases, more overhead steps must be included just to manage the complexity of this web. All project processes consist of productive activities and overhead activities. Productive activities result in tangible progress toward the end product. For software efforts, these activities include prototyping, modeling, coding, testing, and delivery. Overhead activities, which have an indirect impact on the end product, include management, planning, documenting, progress monitoring, risk assessment, metrics collection, configuration control, regression testing, personnel training, and business administration. Another source of overhead is unnecessary scrap and rework.
For those of us with logical brains who want to see some symmetry in the English language, here is disappointing news: English is not very logical or symmetrical.
Progress and quality are the two dimensions of metrics needed for effective steering. Progress metrics are indicators of how much work has been accomplished. Quality metrics provide indicators of how well that work has been accomplished. With these two perspectives, stakeholders can assess more accurately whether a project is likely to deliver predictably against the target outcomes. Although financial metrics are also needed, financial status is simple and well understood. We know exactly how much money has been spent and how much time has elapsed. The challenge with most earned value management (EVM) systems is to quantify how much technical progress has been accomplished so that it can be compared with cost expended and time expended. A reliable measure of earned value (or technical progress as a percent complete) is necessary to accurately forecast the estimates to complete. Traditional EVM methods measure against static targets and usually result in misleading indicators of software progress. However, there is no reason EVM cannot be used with dynamically changing targets and more honest assessments of software delivery.
There are probably more books on agile methods than successful projects with well-documented agile results. Writing a book on agility or project management, where the decision-making process is laid out in the abstract, is easy compared to managing a real project where you must steer through a minefield of uncertainties and the consequences of decisions under game conditions are very real. We should place increased emphasis on publishing measured improvement case studies. They are critical to accelerating the innovation delivered in software.
There are many common double negatives that are proper English. However, there are positive ways to say exactly the same thing with no confusion. Read the rest of this entry »
While quoting the most likely outcome, i.e., the mean, or median or mode of a probability distribution, may be a rough prediction, a more honest representation of the prediction would quantify the full range of possible outcomes. For example, the most likely outcome of 150 days is an accurate portrayal of the expected target date in the two upper graphics of the figure in my last post. However, by expressing how sure we are of that guess—a coin flip in one case and a confident commitment in the other—we are much more honest and transparent in communicating that information to others.
Setting any project’s expected delivery date or its planned resources is a kind of prediction. Many project managers have been faced with the dilemma that it is impossible to predict the future, but that is our job. The best way to improve predictions is to apply what is called Bayesian reasoning.
Suppose you are the project manager for a software product that your organization needs to be delivered in 12 months to satisfy a critical business need. You gather your leadership team, perhaps an architect a development manager and a test manager, and analyze the project scope and constraints to estimate the resources and time needed. You employ empirical models that estimate the project should take 11 months. Excellent! What do you do with that information?