(PDF: 102 KB / 12 pages) In recent times, there have been several movements in software development that appear to suggest that we can defer or eliminate many practices that apparently slow down our ability to develop our products.
As we have all seen in this industry, though, as new ideas gain popularity, there is much that is lost in the translation to the masses. These innocuous statements become embraced a little too tightly. There are claims of universality from all corners of the methodology debate, and that ‘barely sufficient methodology’ often becomes ‘insufficient’, with disappointing or disastrous results.
A balance is required. There are some practices that need to be considered for any project, as the cost of deferring or ignoring them becomes extremely costly to the organization, and results in less delivered value. Balancing appropriate weighting of these practices with appropriate management of change becomes the optimal way of driving a project to successful completion.
This paper describes different types of practices to be considered, approaches to recognize reasonable application along the way, and identifies the practices that we absolutely need to move forward in the lifecycle to ensure that success means creation of the value we actually intended to deliver.
This paper was presented at the 2009 PNSQC in Portland, Oregon by Jim Brosseau.
(PDF: 94KB / 10 pages) (originally presented at the PNSQC, October 13, 2008) If we really want to improve the way we develop software, we need to start by understanding the team itself: what each participant brings to the table. We need to bring all this out into the open, discuss our shared goals, reflect on our cultural distinctions, and leverage our combined strengths.
The better we understand each other on the team, the stronger our trust will be. Our relationships will be more genuine, and our interactions will be more effective. With a consciously managed inventory of our skills, experiences and attitudes, we are better equipped to select which approach will be most effective and how to deploy this refined approach with the team.
(PDF: 102KB / 11 pages) Sustaining meaningful, strategic change in any organization can be difficult, particularly when there are strong personalities and established practices in place. Most initiatives are either too broad in their changes, or fail to address the needs of participants.
Within the Large Format Printer Division at Hewlett‐Packard in Barcelona, despite some of the strongest front‐end analysis practices in the industry, projects continued to face delivery challenges similar to those in many other companies.
Management decided to take action and revert the trend in declining product development efficiency. The authors collaborated with the specific intent to provide lasting and meaningful change for the group.
We describe the initial situation within the group, and the approach to selecting and implementing appropriate changes. We will reveal the deceptively simple viewpoint that was the core of the changes, the effect on the culture and project results that have taken place since.
This paper was presented at the 2009 PNSQC in Portland, Oregon by Jim Brosseau and Carolina Altafulla of HP.
(PDF: 111 KB / 10 pages) (originally presented at PSQT North, and published in the PMI GovSIG newsletter, Spring 2002): an approach for quantifying the costs associated with inefficiencies that most development groups consider normal.
Contact us if you are interested in exploring a comprehensive spreadsheet that you can use to quantify your probable improvement opportunities.
(PDF: 711 KB / 10 pages) (originally published in the Cutter IT Journal, July 2002): An expanded viewpoint of the breadth of activities to consider as “testing”, and strategies for ensuring that your limited testing resources are optimally allocated.
(PDF: 748 KB / 8 pages) (originally published in the Cutter IT Journal, June 2003): Describes the pros and cons of Industry Benchmark data, and how you can best adapt it for your own company’s use.
(PDF: 750 KB / 8 pages) (originally published in the Cutter IT Journal, July 2004): Agile Project Management is becoming the latest in a long line of named approaches to driving projects that promises improved performance – watch for it on a bookshelf or seminar near you. As with most well thought out approaches, though, there is a danger that trimming down the message in order to capture an eager audience’s attention can reduce the positive impact, or even cause a backlash with weak implementations. This article looks at some of the challenges that the Agile Community has faced in getting their message understood in the past, and makes some recommendations for increasing the likelihood of effective use of APM in organizations that want to leverage its strengths.
(PDF: 860KB / 10 pages) (originally presented at the PNSQC,
October 10, 2007 by Robert Goatham): Teams are aware of the key decisions made in a project, but many will not have considered that decision-making is the pervasive thought process that affects even the smallest detail of a project’s outcome. Given that teams that consistently make good decisions are likely to succeed, while teams that make bad decisions are likely to fail, the paper considers the factors that affect the ability of the team to make effective decisions. To assist teams who are interested in improving their capabilities, an assessment tool is provided that allows teams to explore the issues that could prevent from them making effective decisions.
By understanding the factors that drive effective decision making and the relationship between those elements, project teams will be better able to identify weaknesses in their decision making capabilities and address those weaknesses before the project is compromised by a set of bad decisions.
(PDF: 131KB / 7 pages) This is a Case Study about a rare company that understands the value of effective requirements analysis as a basis for success. I originally wrote about Modelsoft in September 2007, here is a more thorough account of their approach and results with the Canadian Fishing Company.
(PDF: 115 KB / 10 pages) This is a completely revised and expanded version of this paper, a refined set of steps that you can adopt that will make it somewhat easier for you to make the leap from the ‘ilities’ all the way to testable statements regarding the quality of the system being built. There is also a Quality Attributes Spreadsheet (Excel: 57 KB / 5 sheets)available that walks you through the steps identified in this article.