This article asks you to recognize and learn from software project failures. Ending a doomed project before it becomes “too big to fail” is a crucial step in preventing that project from becoming a $100M+ failure that bankrupts the company.

In Agile projects, it's a common practice to visualize and share project status in “big visible charts” on a wall of the project room. Lean systems also use such devices. "Kanban," in Japanese means, loosely translated, 'card or sign'. In a Lean production system, Kanban is a method which uses standard units or lot sizes with a single card attached to each. A new card is "pulled" into the system only when the work represented by an "in progress" card is completed. In this paper, I explore visualization methods found widely in agile projects these days, and then propose using Kanban Boards to organize three viewpoints (Time, Task, and Team) so that the whole team understands the current status of the project and can work in an autonomous, motivated and collaborative manner. Finally, I introduce a software tool “TRICHORD” that implements Kanban Boards to realize project visualization from the three viewpoints.

A set of measures was determined that allow analyses of TSP projects in terms of their fidelity to the TSP process and their project performance. These measures were applied to a data set of 41 TSP projects from an organization to identify their strengths and weaknesses. Software engineering teams already using TSP for soft-ware development can use the measures provided in this report to gain further insight into their projects.

You are the project manager of a large project and testing is uncovering faults, trouble reports are starting to pile up and the release date is coming soon. Are they going to be fixed on time? What could you do to help? Are there any bottlenecks? Where should you assign more resources? Does this scenario sound familiar? Have you been there? This article will explain how you can answer these questions by using an old method called Line of Balance in a new way.

Discussion on ‘burn up’ charts and how they can be effectively used by project managers for reporting progress. The discussion takes into account work in progress (wip), outstanding inventory of features and other phases of development. Many good discussion points are presented as well as good observations about reporting project progress.

This article discusses the need to manage software development projects from a financial perspective and not just with estimates and progress tracking.

In recent Agile Scrum projects the layout of the Task cards has changed mostly because of the team’s personal tastes. The concept has not changed and the team agrees with the current solution. We know actuals and ideals are conflicting, and it is not Agile Scrum. Now, we separate them by having a different background on the Task cards, and speaking ideal hours the entire day and accounting for actual hours at the end of the day.. We feel that we have found the best solution to secure our sources of income and still follow the Agile Scrum methodology.

The test manager has two responsibilities: to report the right information, and to report the information right. Both are equally important. If you don't have the right information, you're not doing your job. If you don't report it so that it's accepted, valued, and acted upon, you might as well not be doing your job. To address both topics, this paper is organized around the situation in which the test manager presents "the public face" of the testing team: the status meeting. It covers the information to be presented and the needs of the people involved (which govern how to present that information usefully).

As Scrum teams quickly release new software, Bob Martin recommends to monitor that the team is not hyper-productively making a mess! You have to make sure they are practicing the disciplines that produce data that can be measured.

Managers can build better, more efficient teams and successfully navigate the toughest project environments in tandem by reading a set of human gauges (indicators) provided by their project team. Reading these gauges requires observation of, and listening to, some rarely utilized aspects of teaming. Once collected, the gauges act as essential leading indicators that provide insight into building stronger teams and arriving at a project destination safely and on time.