Directories |
Search U of M
|
|
|
|
|
||
|
|
TwinSPIN Newsletter: Volume 2, Issue 3March 1, 2000 Editor's Note As you may have already noticed, this TwinSPIN Newsletter did not arrive early in the month as it had for the first four issues. It is even a bit delayed from the promised mid March distribution. Your harried but hopeful newsletter editors have been swamped with their day jobs, delaying this issue and driving us to a bi-monthly distribution schedule. This newsletter, as stated in the title, satisfies the March - April 2000 issue. The next issue, covering May - June, should be available in mid May. Thank you for all the support and encouragement as we go above and beyond to bring you this newsletter. Part of the reason for this delay was my (i.e. Pat Wegerson's) attendance at the National SEPG 2000 Conference in Seattle, WA. The conference theme was "2000 Ways to Make Software Better" and I'd say that it lived up to its theme. This was my fourth National SEPG Conference and it was the best I've attended. Nearly all of the presentations and tutorials I attended were well done, thought provoking, and useful. If you've never been to an SEPG conference, I highly recommend it. One of the biggest benefits of attending this conference is a motivational shot-in-the-arm when you're surrounded by 2000+ other professionals working on software process quality. Start planning now to attend next year's National SEPG Conference on March 12-15, 2001 in New Orleans, LA. As always, thanks to our contributors, and Pat O'Toole, for providing articles to the TwinSPIN newsletter. Also thank you to Esther Derby for coming through yet again to publish this newsletter. Note: I received a request to have the newsletter in a form more agreeble for printing individual articles. As a novice HTML developer I'm still working on doing that (i.e. suggestions are welcomed!). Until then, I suggest a "cut-and-paste" procedure to a document file. The end-of-lines may not be where you'd like but it's the best I can offer right now. Send letters-to-the-editor, comments, questions, submissions, or anything else relevant to Pat Wegerson at weger002@tc.umn.edu or at 612-448-1335. Esther Derby can be reached at estherderby@worldnet.att.net .
Writers Guidelines The goal of the TwinSPIN Newsletter is to provide articles and information with a real world perspective that will be useful to you, the readers. And who could know more about real world software process improvement than the members of a SPIN? If you've ever had the urge to be an author and have an insight you'd like to share, consider writing an article for the Newsletter! In general, articles should be fairly short, not more than 1000 words (since the Newsletter is distributed electronically, we can't accommodate graphs and figures at this time). We're looking for articles with a "how-to" bias, and we also like to put a lighter piece in each issue. Articles that are academic or commercial are less likely to be of interest. If you have an interest in writing an article or contributing one that has been previously published, please contact Pat Wegerson at weger002@tc.umn.edu or at 612-448-1335.
TwinSPIN Meetings March Meeting: April Meeting: Meeting Directions: For maps:
Crisis Management by Gary Robinson Everyone has experienced a project crisis. Some have been hurt by crisis, some enjoy it. Some managers enjoy it so much that they create it. Regardless of feelings about crisis, the potential for good or bad consequences is the same, depending on the manager's approach. Crisis causes so many problems because it demands immediate attention. If the day-to-day practices don't solve the issue quickly, the pressure to act becomes strong. Those involved may feel pushed by the expectations of others to act too quickly. Reacting without adequate information, or involving the right people, results in poor solutions and increases stress, with no learning about preventing future crisis. Causes of crisis Following are examples of causes identified by hundreds of project teams:
A typical crisis sequence with negative results There is no one cause of crisis, but the following illustrates a common
series of events. Appreciating what the manager does wrong in this sequence can
help managers prevent or resolve crisis of any type. The initial pressure to get the job going is strong. People bury themselves in immediate work without planning, understanding client needs, getting to know each other, or developing the team. b. The imposed schedule starts to slip. The manager reacts negatively be-cause of the slippage. To protect themselves, team members stop reporting slippages. Status is reported as "fine" so the truth is hidden as long as possible.
c. The project manager figures it out and looks for the
person The manager is angry because information about the slippage was withheld, and does not understand that it was withheld because of his/her negative reaction to bad news. d. Team members accuse each other. Team members unwilling to accept all the blame naturally blame other team members. The team starts to fall apart. The real fault is with the project manager for imposing an unrealistic goal, not openly acknowledging that it is unrealistic, and not offering support to the team to achieve the impossible. Team members know this, but no one will con-front the project manager even though they knew from the beginning there was not enough time. e. Everyone works overtime, without much improvement. Pressure is put on the project manager to "do some-thing." Interventions are often "put in more hours" and/or "new resources to clean things up." This is demoralizing for the team. f. Everyone scrambles on a day-to-day basis. The feeling is "if we can get through the next month..." This is management by crisis. Negative emotions increase and people may actively dislike their work or leave. The project manager may achieve apparent project success by pushing harder, but has set the organization up for fail-ure in the future. His/her heroic, pressure-cooker style has set the company up to repeat the same process on the next project; they have not learned how to prevent crisis or resolve it effectively. A better model for crisis intervention A major role for managers is to develop their team's problem-solving skills so they become more self-dependent. To do this, the manager must resist the temptation to take over. It is important to not panic, slow the process down, and get the team involved. The manager can resolve project issues more effectively, reduce stress, and develop team skills by intervening in the following sequence. It is possible for crisis to have a positive effect on the project, team morale, and client relations if it is dealt with appropriately. a. Acceptance
This article came from Software Productivity Center Inc.'s E-ssentials!, a free, biweekly e-newsletter with how-to's for successful project management and practical software development. To subscribe or view past issues, visit http://www.spc.ca/resources/essentials/index.htm.
Do's and Don'ts of Software Process Improvement #3 by Pat O'Toole [Editor's note: This is the third of several short articles on "Do's and Don'ts" from Pat O'Toole's experience working in an SEPG. This is written for managers and SEPG members who are implementing CMM-based improvements in their organizations.] DO: Take Time Getting Faster Level 2 in the Capability Maturity Model is called “Repeatable,” but even Level 1 organizations exhibit repeatable behavior. For instance, many Level 1 projects are scheduled to complete on the earliest date with a non-zero probability of success. The thinking, which unfortunately appears to be repeatable, is that if everyone works 60+ hours per week, and nobody gets sick or takes weekends or holidays off, the project might just finish on time. And now your senior management has proclaimed that the overarching goal of the Process Improvement Program is to reduce cycle time. They are not being unreasonable – it's hard to deny that for many software-intensive products the primary competitive dimension is time to market. Customers, whether internal or external, are always clambering to get new products and features in an ever-decreasing time frame. But as a member of the SEPG you fear that this edict simply gives the projects an excuse to circumvent any existing processes and standards in order to get the job done any way they see fit. Customers apply schedule pressure as part of a “ritualistic dance.”. They get you to commit to delivering in twelve months in the desperate hope that they will receive the full product in fifteen months, or alternatively, that they will get 60% of the core functionality by the committed date. You know it, they know it, and yet the charade plays out release after release. It's just like budgeting’s ritualistic dance – if you need $5M for your project you request $7.5M, knowing that 1/3 of the budget will be cut back through the approval cycle. We all know the tune and the dance continues! So what do the customers REALLY want? They want to believe! Customers want to know that when you commit to delivering a product on March 31 that it will be available for implementation on April 1 (an appropriate date?). Although they claim they want the software faster, they really want it more predictably. As much as the customers want to believe, the software development staff wants to be believed. They would like their managers to leave their professional integrity intact by accepting and even defending their estimates. They would like senior management to understand and mitigate the devastating effects of golf course commitments and uncontrolled scope creep. They would like their customers to realize that it is in their mutual best interest to plan and execute projects in a disciplined manner. Finally, they would like to see their spouses and children more often than Sunday evenings! Rather than establishing a goal of becoming faster, the organization would be
better served initially with the goal of becoming more predictable. To
achieve this goal, the organization must: Disciplined planning and execution significantly reduce the variability of project results. It also establishes a solid foundation for getting projects done faster, the organization's ultimate goal. Since you are unlikely to achieve sustainable cycle time reductions without first achieving reasonably predictable results, follow Steven Covey's advice and “put first things first.” The SEPG’s challenge is to convince senior management that generating more reliable estimates and predictable project performance is a necessary prerequisite to reducing cycle time - and that once customers believe, once estimation credibility has been established, the tune of the ritualistic dance will be altered forever. Copyright © Pat O'Toole 2000 Pat O’Toole is one of the most active SEI authorized lead assessors and is a Software Process Improvement Director at TeraQuest Metrics, where he provides consulting, training, and assessment services to major clients. He has conducted a number of formal and informal assessments, including two Level 5 CBA IPIs. With over 20 years of software development, project management, and consulting experience to draw from, Mr. O’Toole works with all different levels of management and SEPGs in establishing, evaluating, and sustaining their process improvement initiatives. He is a popular instructor who supplements standard training material with his vast array of case studies and humorous examples. Pat O'Toole can be reached at:
Test Best Practices By Dick Hedger Following are the test best practices as determined by the attendees at the January 4, 2000 TwinSPIN meeting. From the breakout group "Test Best Practices" inputs, I have summarized the most often mentioned best practices:
Needs & Leads Editor's Note: Needs & Leads is a feature of both the TwinSPIN newsletter and web site. Needs & Leads provides a forum for requesting and for offering SPI related goods and services. This is offered as a benefit to TwinSPIN members. Needs & Leads may include commercial offerings if the item may benefit the TwinSPIN membership. If, however, you find any offering inappropriate, misleading, or a detriment to TwinSPIN, please contact Pat Wegerson at weger002@tc.umn.edu or Mark Glewwe at glewwe@millcomm.com and we will work to resolve or remove the questionable item. Needs: No
new needs
Announcements & Calendar Recent and upcoming U.S. SPIN meetings:
About TwinSPIN For the Minneapolis/St. Paul Regional Area TwinSPIN Mission Statement Meetings are normally held on the 1st Thursday of each month from 6-8 PM. TwinSPIN web site: All articles, reviews and commentaries are copyright by the authors, unless otherwise noted. All rights are reserved to the authors. We encourage sharing the TwinSPIN Newsletter in whole or in part if copyright and attribution are always included. |
|
|
||||
|
