|
Title
Title
|
Author(s)
Author(s)
|
Occasion
Occasion
|
Format & Size
Format & Size
|
Copyright Holder
Copyright Holder
|
|---|---|---|---|---|
| Traditional project management methods do not support knowledge work: Do our PM methods fall short for the 21st Century? | Stan Rifkin | September 28, 2016 meeting of the Washington DC Chapter of the Project Management Institute | Master Systems Inc. Portions copyrighted by QSM Inc. and Prentice-Hall. | |
| Abstract. There is little new in project management since the 1950s. Yet the subjects of PM have grown to include projects whose work products are invisible (e.g., designs, ideas, discoveries, software, novels, movies, works of art, organizational culture change. What of traditional PM can be applied to the creation of invisible products? What else is needed? | ||||
| A great software/systems process is great only if it is implemented: A method to manage the soft side of implementation | Byron Fiman and Stan Rifkin | 2014 North American Software Engineering Process Group conference (May) | No copyright. | |
| Abstract. Key human and cultural factors are widely acknowledged to be critical predictors of successful process improvement. Field survey results presented at previous conferences in 1997 and 2009 demonstrated that soft factors continue to represent major barriers to successful implementation. Despite these findings, soft variables are rarely systematically assessed and managed like hard factors. Often, they are relegated to a one-time training session, a vision sound bite in an off-site meeting, or stamped on a laminated wallet card. At best, soft change management issues are managed in a reactionary mode, often in response to a crisis or symbolic event. Generating genuine management commitment, managing the inevitable resistance to change, building high-quality communication vehicles, and establishing reward systems that elicit the desired new behaviors provide significant challenges for change agents and are largely responsible for the poor track record of process improvement. | ||||
| Things I Wish Someone Had Told Me When I Began | Stan Rifkin | 2013 North American Software Engineering Process Group conference keynote address (Oct) | Master Systems Inc. | |
| Abstract. Here are four areas that would have greatly accelerated my effectiveness as a process improvement advocate if I had known them early in my quest. They are offered in the spirit of beginning to create a framework for understanding all of the other things we hear about process improvement. (1) The learnings of another person or organization need to fit this new situation in order to use them. (2) We do things for reasons and those reasons matter. So, we need to understand the frame(s) of reference of the parties and then re-frame. (3) If we want to help organizations improve, seems like we should start by learning how organizations work. And improvements usually focus at certain levels, such as individual, team, and enterprise. The learnings and methods are rarely interchangeable across the levels. (4) While it is natural to focus on resistance, it is mostly unnecessary -- now. | ||||
| Industry panel: Best practices for systems engineering workforce development | Stan Rifkin | 2013 National Defense Industrial Ass'n Systems Engineering conference (Oct) | Master Systems Inc. | |
| Abstract. Development of a capable systems engineering workforce, in both government and industry, is a critical cornerstone to the effective definition, acquisition, management, design, implementation, and deployment of defense systems. There is no substitute for systems engineering experience, yet as our workforce matures, we must as an industry consider how to grow and sustain our systems engineering capabilities and develop tomorrow's leaders. This panel will bring together executives from defense industry companies to discuss best practices for systems engineering workforce development. Among the topics to be discussed include:
| ||||
| Quantitative Risk – Phase 1 Interim Technical Report | Roshanak Nilchiani & Stan Rifkin et al. | Systems Engineering Research Center, Sept 2013 | Stevens Inst. of Technology, "This material has been approved for public release and unlimited distribution except" as noted in the report. | |
| Abstract. Our usual conception of risk is that it is static, needs to be addressed at the beginning of a project or event, and that the sources of risk do not interact. This TR offers the view that risks evolve and emerge as conditions unfold, and that risks are connected in the same way that system elements are: risks can propagate. We propose ways to quantitatively characterize such connected and evolving risks, and offer at least one new mitigation (isolation, buffering). In addition we offer for further study the observation that some organizations are very good at addressing risk. What are they doing? What is their secret? | ||||
| Helix: Investigating the DNA of the systems engineering workforce | Stan Rifkin & Helix team | 2013 INCOSE International Symposium (June) | Systems Engineering Research Center | |
Abstract. Helix is a longitudinal research project that seeks to characterize the existing defense-oriented systems engineering workforce and answer several questions:
| ||||
| An introduction to the special issue of Journal of Enterprise Transformation: Enterprise change and continuity | Stan Rifkin | Journal of Enterprise Transformation (2011), vol. 1, issue 2, pages 95-97. | Journal of Enterprise Transformation | |
| Abstract. Enterprise transformation is usually construed as large-scale change. Is change the opposite of continuity? Is continuity the same as stability? These are important questions, particularly to those seeking to implement enterprise transformation, because they stake out the intellectual territory and inform the questions and challenges that the enterprise must address. Are change and continuity seen as forces that compete for energy and mind-share during transformative processes? Is there a view that change and continuity are required, that they do not really compete, especially if they alternate? These are some of the questions we address in this special issue. | ||||
| Raising questions: How long does it take, how much does it cost, and what will we have when we are done? What we do not know about enterprise transformation | Stan Rifkin | Journal of Enterprise Transformation (2011), vol. 1, issue 1, pages 34-47. | Journal of Enterprise Transformation | |
| Abstract. Though we speak about transformation, we know little about even the most rudimentary aspects of organizational change. This is less a gap and more of an abyss: we have practically no quantitative information on transformation, except in some cases, an approximation of the total cost. This article is a list of the principal areas of knowledge that we lack and the impact of that lack. The list becomes a research agenda for transformation. | ||||
| Conservation of information: Reverse engineering dark social systems | William Lawless, Stan Rifkin et al. | Structure and Dynamics: eJournal of Anthropological and Related Sciences, 2010, vol. 4, no. 2 | On-line | No copyright. |
| Abstract. Collecting information from well-defined organizations for social network analysis (SNA) is relatively straightforward. For "Dark" social networks, for example, illicit drug gangs or terrorists, uncovering information to compute an SNA is orders of magnitude more difficult. However, even when the information is readily available, the signals collected from social networks have not led to valid predictions about their actions or stability. This failure has led to a wide request for new social theory to better understand the effects of interdependence in social networks and in social organizations. For example, Barabási concluded that room needs to be made for a new theory "to understand the behavior of the systems ... [and] the dynamics of the processes ... [to] form the foundation of a theory of complexity." | ||||
| Systems of systems: Answering the organizational implications | Stan Rifkin | 2010 Annual Defense Systems Engineering Conference, National Defense Industrial Association, San Diego, California, October 25-29. | PDF (2.15Mb) | No copyright. |
| Abstract. Last year you heard the problems and this year you can hear the solutions, and working together in this session tailor the answer to your particular organizations, customers, and what you are trying to optimize. Less of death by PowerPoint and more interactive problem-solving using a library of long-standing tools and methods. Most of the organizational-related problems of SoS have been solved in other settings, so this tutorial seeks to marry the well-known solutions to your specific issues. The format will be question and (long) answer; participants should be prepared to describe their environments and concerns, and then the guide will expose the whole group to what successful organizations have done to address those very subjects. Most of the material will be new to the participants because it comes from sources outside of our usual engineering, science, and technology backgrounds. One objective of the tutorial will be to equip participants with a lens with which to best see organizational dynamics and leverage points. Remember: some problems that look technical, such as requirements allocation, are usually results of how engineers are organized. Participants will leave not only with the answers to their own questions and the others' in the room, but also a deeper understanding of approaches that are off of our usual radars, outside of our normal experience-base -- along with advice about where to look in the future as new organizational challenges arise. | ||||
| The counter-case: How to interfere with terrorist learning | Stan Rifkin | New Horizons Research Conference, the George Washington University, Ashburn, Virginia, October 8-9, 2010. | PDF (264Kb) | No copyright. |
| Abstract. Can we use theory of social systems interaction -- for example, Parsons' theory of action and GWU's extension to learning -- to interfere with, deny, and otherwise disrupt learning by terrorist organizations? Presented are a few prospects as a thought-piece, the beginning of a conversation. | ||||
| Explaining success AND failure of engineering improvements | Stan Rifkin | Washington DC area Software Process Improvement Network, October 6, 2010. | PDF (817Kb) | No copyright. |
| Abstract. We usually take for granted the goodness of an enterprise's choice of overall direction and strategy; we sometimes observe that performance is not in line with strategy and prescribe some lining-up exercise. I have found that many engineering quality and process improvement initiatives fail because they go against the strategy and therefore one or the other of them is "bad" and should be changed. In other words, in trying to explain why it is that some enterprises embrace and succeed in the improvements yet others do not, the fit with strategy may be central and powerful. In particular, when strategy and improvement are aligned, the improvements go very quickly and painlessly, belying the myth that there is always resistance to change. Therefore, as agents of change we need to add tools to be able to quickly assess strategy, improvement, and the mutual fit, and then know what to do about a possible misfit. They are the topics of the presentation. | ||||
| What is the best way to develop systems? Continuing the conversation about agile and plan-driven methods | Stan Rifkin | Washington DC area Software Process Improvement Network, August 4, 2010. | PDF (1Mb) | No copyright. |
| Abstract. There is a tension between disciplined, plan-driven methods of systems development and more ad hoc, agile ones. Some participants and observers take an all-or-nothing stance, while there has been an emerging practice trying to blend the best of each approach. This poses the question of what IS, after all, the best of each method? How could we tell what one life cycle approach offers that another does not? In the end the answer depends upon what we are trying to optimize: rapid delivery of value or high assurance. Besides presenting a framework containing the factors to take into account when deciding on a life cycle model, there will also be perhaps the first local presentation of the Incremental Commitment Model, successor of the spiral model and created by the same author, Barry Boehm. | ||||
| Organizational assessment models for enterprise transformation | Nathan Perkins, Ricardo Valerdi, Deborah Nightingale( all MIT) & Stan Rifkin | 2010 International Council on Systems Engineering (INCOSE) Annual Conference, Chicago, Illinois. | PDF (263Kb) | No copyright. |
| Abstract. Organizational assessment is becoming increasingly important, both as a cross-time and cross-industry measurement and as a guiding force in enterprise transformation. Assessments provide crucial information about strengths, areas for improvement and potential investment strategies for achieving performance benefits. As performance is being recognized as a complex and multifaceted construct, assessment tools seek to incorporate and reflect a holistic measurement of performance across multiple dimensions such as stakeholder value, leadership, culture and quality. | ||||
| An ab initio solution of interdependence: Social organization with first principles | W. Lawless, Stan Rifkin and D. Sofge | Advances in Quantum Theory conference, International Centre for Mathematical Modelling and Linnæus University, Växjö, Sweden, June 2010. | PDF (112Kb) | No copyright. |
| Abstract. A special issue of Science, the National Academy of Sciences, the military, and economists have called for a new theory of interdependence, call it iota. Constructed around the notion of bistable social reality (i.e., complementarity between conjugate or Fourier pairs), we have developed a social physics of iota for organizations and systems of humans, machines and robots that has shown some validity. But because of the loss of meaning associated with understanding iota states or interactions between social Fourier pairs, we consider it high-risk research. | ||||
| I am a change agent: What do I do and how do I learn how? | Stan Rifkin | 2010 North America Software Engineering Process Group Conference, March, Savannah, Georgia | PDF (349Kb) | No copyright. |
Abstract. Engineering process improvement can be a significant organizational change: new ways to work; new ways to measure and new rewards; new jobs, titles, and ways to organize; and new skills, both technical and people-related. Bottom line: Successful implementation will require us to make significant changes in how we think and behave.
It is rare for change agent skills to be included in software/engineering curricula or even training. How can we find out which are the most important skills and the best way to attain them?
| ||||
| Improvement implementation barriers: Then, now, and future strategies | Stan Rifkin & Byron Fiman | 2009 Software Engineering Process Group Conference, March 26, Austin, TX | Master Systems Inc. | |
| Abstract. We compared the responses to a questionnaire given about 10 years ago with a current set to see if there are any differences in improvement implementation barriers and accelerators, and whether the antidotes from the field differ, too. In sum, there were no significant differences. It was voted one of the top ten papers at the conference! | ||||
| (Secrets of a) Process Whisperer | Stan Rifkin | 2007 Software Engineering Process Group Conference, March 26-29, Austin, Texas | PDF (274Kb) | Master Systems Inc. |
| Abstract. From afar, horse and dog whisperers appear to get recalcitrant animals to obey them without saying anything aloud, seeming to whisper "secret" commands into an animal's ear. When we see this we attribute such gifts to magical powers, hocus pocus, hypnosis, and imbue supernatural powers to the "whisperer." We have also seen these same things happen when certain strong personalities speak to executives: even though we have told those executives virtually those very same words a thousand times, when a Process Whisperer says it there appears to be some secret communication and the executive becomes interested for the first time! What "whisperers" do is to get their targets into the natural states, back to where their instincts take over, where they react in an inborn, almost physical way. The written presentation is brief because, after all, whispering is inherently oral! | ||||
| "I'm the Lead!!?? Now what do I do?" - Continuing the conversation | Stan Rifkin | February 19, 2007 meeting of the San Diego Software Improvement Network | PDF (1.27Mb) | Master Systems Inc. |
| Abstract. The January 2007 SD SPIN meeting presenter did a wonderful job introducing the challenges of being a new technical manager and offering some heuristics about how to be effective. This presentation uses that one as a basis and offers more depth and some of the reasons why the rules of thumb might work. The previous speaker correctly answered a number of questions from the participants with "It depends." This presentation will give more details on what exactly the answer does depend. And it will also supply a "buyer's guide" to information on leadership, management, and teamwork. In addition, the presentation will address such questions as: what is the difference between a leader and a manager and what difference does the answer make; does the size of a team make a difference in how a leader should behave; should a leader care about what the team does (technical vs. sales, for example) - isn't leadership a professional onto itself; seems like leaders have to be able to do everything (mentor, strategize, inspire, critique, make decisions, etc.), but who can really do that and aren't we setting up leaders for failure by having such high expectations; are leaders made or born (trainers need to believe they are made, but what is the data); what is the best way for teams to make decisions (consensus?); how does psychology mislead us when dealing with groups; and what resources are available to those of us who do not have natural people skills (like the speaker!) | ||||
| Best commercial practices for acquiring systems of systems | Stan Rifkin | University of Southern California's Center for Systems and Software Engineering Executive Workshop, February, 13, 2007 | PDF (818Kb) | Master Systems Inc. |
| Abstract. Probably the biggest problem in creating systems of systems is acquiring them. Are there any commercial best practices that the rest of us can use as a template? This presentation suggests one: European Organization for Nuclear Research (CERN), where distrust of partners is the rule. The biggest difference between government acquisition and commercial is the knowledge of capability, even if vague vs. "Can do" attitude. Government: "We must have something this big!" Commercial: "We don't think we can built something that big." | ||||
| Why do I have to learn about organizations? I am a software engineer/computer scientist! | Stan Rifkin | Keynote address at the 2006 International Conference on Computer Science and its Applications, at National University, San Diego, California, June 27-29, 2006 | PDF (283Kb) | Master Systems Inc. |
| Abstract. Most systems fail for organizational reasons, not for technical ones. Many of our solutions are technically adequate, but they cause organizational problems or do not take into account organizational issues, and that is why so much technology is not implemented, adopted, or deployed. Knowing how organizations work greatly improves the chances that our technical solutions are appropriate and will actually be used. Besides, big work, significant work, is done by organizations for organizations. | ||||
| How much should we spend on quality assurance? | Stan Rifkin | March 28, 2006 San Diego chapter meeting of the Society for Software Quality | PDF (359Kb) | Master Systems Inc. |
| Abstract. You would think by now that we would be able to answer that question definitively! You would think that we would be articulate about how much testing we have to conduct, when to stop, what exactly to test, and what product quality is required by the marketplace. This presentation is based on the pioneering work of Barry Boehm and LiGuo Huang at the USC Center for Software Engineering and is a contribution to answering the questions above, by taking a context-sensitive approach, one that looks carefully at the value of what is being developed, since not all parts have equal value to stakeholders. Practical application of the method is illustrated, along with the theoretical underpinnings. | ||||
| Explaining success & failure: Value-based software engineering | Stan Rifkin | March 20, 2006 joint meeting of the San Diego Software Process Improvement Network and the San Diego chapter of the Association for Computing Machinery | PDF (258Kb) | Master Systems Inc. |
| Abstract. There is very little new in the overall framework of how to engineer software, but this is! Barry Boehm and Apurva Jain at the USC Center for Software Engineering have been doing some serious thinking about how to best manage and develop software. This presentation describes the fruits of that powerful thinking by illustrating the five components of the framework: negotiating a win-win solution, characterizing and attending to dependencies, the relative worth of each of the important variables (cost, schedule, features, etc.), the relationship between what we do and what happens, and how we make decisions. The framework will be animated by showing how the components interact and are traversed. And then the framework will be applied to the question of "how much quality assurance is enough?" | ||||
| Combining systems & software engineering: Who's in charge of organizational aspects? | Stan Rifkin | Executive workshop, Center for Systems & Software Engineering, University of Southern California, March 14-16, 2006 | PDF (252Kb) | Master Systems Inc. |
| Abstract. The systems we develop impact those who consume and use them, but who in systems engineering is in charge of making sure to attend to the human and organizational impacts? We need to shift our world view in order to understand how our systems are seen by those impacted and then take responsibility for that impact, hopefully by prospectively designing the impact to be what we all intended. The presentation gives examples of the new world view and how we might be successful at adopting it. | ||||
| How do I know if I can learn from your experience ? (Paper v1.2) How do I know if I can learn from your experience ? (Slides v2.0) Comparing patterns: elevation, scatter, and shape | Stan Rifkin | Software Engineering Process Group Conference (SEPG), Nashville, Tennessee, March 2006 | PDF (859K, 1.3M, 503K respectively) | Master Systems Inc. |
| Abstract. The SEPG Conference is, at its core, a sharing of practical software process improvement experience. When we hear the experience of others how do we know if it will apply to our situation? How do we know what variables control the applicability of another organization's experience to our particular situation? Comparing organizations, it turns out, is a settled question in organizational studies. This presentation introduces SEPG members to a free, well-documented tool that helps to address what we need to know about another organization to recognize if its lessons may be applicable to mine. You may be surprised by how few variables there are that really make a difference, that we do not need to know "everything" in order to make reasonable inferences. The principal tool operationally defines "misfit" as a serious difference in the values of the variables that have to match in order for one organization to learn from another. Therefore, as we listen to SEPG Conference presentations this tool is so easy to use that we can answer for ourselves whether the lessons we are hearing are a misfit for us. | ||||
| Appropriate life cycles depend upon enterprise strategy | Stan Rifkin | Development and Deployment of Product Software 2005, the first ever workshop on product software, held in conjunction with the 3rd International Conference on Computer Science and its Application, National University, San Diego, California, on June 27-28 | PDF (93Kb) | Master Systems Inc. |
| Abstract. Suggested that selecting the best life cycle depends upon a number of factors. One of them is the market discipline or strategy of the organization. Certain strategies are aligned -- that is fit -- with corresponding strategies. | ||||
| What is the best way to develop software? Continuing the conversation about agility and plan-driven methods | Stan Rifkin | June 20, 2005, meeting of the San Diego Software Process Improvement Network, which began the fifth year of SD SPIN | PDF (652Kb) | Master Systems Inc. |
| Abstract. Reviewed and updated Boehm & Turner's Balancing agility and discipline: A guide for the perplexed since its publication, noting in particular that we are still perplexed about how to develop software intensive systems of systems, free and open source software, geographically distributed development, and how to obtain CMMI compliance for agile methods. | ||||
| Is there a misfit between the Capability Maturity Model/Capability Maturity Model Integration (CMM/CMMI) and corporate strategy? | Stan Rifkin | Intel Corp. Software Process Improvement Network meeting on April 13, 2005. | PDF (600Kb) | Master Systems Inc. |
| Abstract. While the part of Intel that fabricates integrated circuits is clearly a quality leader, in the software area innovation may be dominant and therefore the CMM/CMMI may offer little guidance. In that respect the software part of Intel might be "allergic" to the CMM/CMMI. | ||||
| Learning from a great many sources: Summary of SEPG Conferences since 1988 | Stan Rifkin | Software Engineering Process Group (SEPG) Conference 2005 in Seattle, Washington, on March 9th. | PDF (548Kb) | Master Systems Inc. |
| Abstract. There are patterns, repetitions in the SEPG Conferences over this many years. Patterns include: one size does not fit all, executive sponsorship is essential but there are exceptions, the human side of technology change is important, assessment is different than improvement, software process improvement (SPI) is part salesmanship, strict quality and measurement do not work for every organization, there are only a few ways to execute the key practices, it is difficult to get SPI to stick, changes in management can derail improvement, one model or the other does not make implementation easier, resistance to change is common and natural, and teamwork is essential. Along with these patterns are anti-patterns and also evidence over the years that many of the patterns are not accurate. This session may greatly accelerate those new to SPI, and the veterans will be able to compare their list of learnings with the presenter's. This presentation is a lively point-counterpoint, challenging the wisdom repeated without question at every SEPG Conference. The presenter has attended every SEPG Conference, except one (2003). The presentation is the heart of what the Conference offers: condensed, practical advice from many sources who have actually performed the work. |
||||
| Combining operational excellence and product innovativeness | Stan Rifkin | Robert Bosch software engineering conference 2004 near Stuttgart, October 26-27. | ZIP of Power Point (913Kb) | Master Systems Inc. |
| Abstract. Keynote address to an audience of this provider of the electrical and electronic components in automobiles, esp. those of German manufacture. How to combine two of The Disciplines of Market Leaders: operational excellence and product innovativeness. This is considered very difficult, usually impossible, so the presentation carefully shows how quality and innovation can be achieved together. | ||||
| Reviewing 25 years of testing technique experiments | Stan Rifkin | San Diego Chapter of the Society for Software Quality, August 24, 2004 | ZIP of Power Point (81.65Kb) | Master Systems Inc. |
| Abstract. An article of this same title recently appeared in Empirical Software Engineering. This presentation is a summary of the results reported there, translated for quality professionals. The article examined virtually every paper written on unit testing (that is, white box or state testing) and collected the results so that inferences could be made about the best way to test a computer program where one has the source code. Testing is a difficult subject because, even for a small program, it would take approximately an infinite amount of time to cycle through all of the states. Therefore, only a (tiny) subset of the states can be exercised. Which ones? That is the subject of this presentation. | ||||
| Two good reasons why new software processes are not adopted (and what to do about them!) | Stan Rifkin | Proceedings of the 2003 Workshop on Adoption-Centric Software Engineering, held in conjunction with the International Conference on Software Engineering, Portland, Oregon, May 9, 2003. The entire proceedings are available from the Software Engineering Institute.Click here to find out more. | PDF (276.19Kb) | Institute of Electrical and Electronics Engineers |
| Abstract. There are many reasons we do not adopt software engineering processes, including those associated with tools. This paper presents two of the most persuasive reasons, based on a literature review of 175 references. And suggests what, as change agents, to do about them. | ||||
| Why new software processes are not adopted | Stan Rifkin | Advances in Computers, vol. 59, 2003, pp. 83-126 | PDF (815K) | Permission requested from Academic Press division of Elsevier |
| Abstract. Why do we often appear not to do what is best for us, or at least what someone else thinks is best? To what extent do the reasons have to do with what is being suggested vs. to how the implementation is planned and executed? Is there a way to accelerate the rate at which the implementation of process adoption can be achieved? These questions are addressed by reviewing the considerable literature on implementations of software engineering, information systems, and quality improvement.(ver. 1.2) | ||||
| Is the CMM an impediment to innovation? | Stan Rifkin | EDS annual CMM Conference, July 2002 | Microsoft Word | Master Systems Inc. |
| Abstract. The CMM is tuned to organizations that seek operational excellence, one of three strategies or value propositions. Organizations that have innovation as their value proposition will find little guidance in the CMM. | ||||
| Is process improvement irrelevant to produce new era software? | Stan Rifkin | European Conference on Software Quality 2002, Helsinki, Finland, June 2002 | PDF (285K) | The Springer-Verlag, reprinted here with permission |
| Abstract. Narrow focus is the key to success for organizations of all kinds and sizes. Focus can be diluted by emphasizing the "wrong kind" of software process improvement. That's right: traditional software process improvement may impede the successful development and deliver software, particularly innovative and total solutions. In fact, adherence to traditional software process improvement can cause an organization to become blind to competitive forces. This presentation gives a preview of a new set of improvements that are tailored to the new styles of software development and to the new market realities about time to market, our tolerance of quality concerns, and relentless focus on convenience. | ||||
| What I would do differently if I wrote the SEPG Guide today (draft 0.2A) | Stan Rifkin | Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona, February 2002 | PDF (167K) | Master Systems Inc. |
| Abstract. The Software Engineering Process Group Guide (SEPG Guide) was researched and written by Priscilla Fowler and Stan Rifkin in 1988-1990, and published by the Software Engineering Institute in 1990. It is about how to improve processes every day. Many of the observations reported in it have proved useful over the years of application. Some additional information would have added significantly to its applicability, particularly (not in any order): one size does not fit all, the importance of process improvement by stealth, how we are misled by psychology and should pay attention to sociology, what patterns of adoption look like, a fresh look at "resistance," and how engineers might approach the subject of deployment. | ||||
| The CMMs are relevant to modern software development environments | Stan Rifkin & Jerry Lankford | Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona, February 2002 | ZIP of PowerPoint (264K) | |
| Abstract. We cannot afford "People's uniqueness is used to mold a process to their individual and collective strengths and diversity." We need long-running, robust engineering methods to develop the life-critical systems that will last decades, the initial development of which is only a small fraction of the investment. We have to focus on quality, trustworthiness and maintainability for those systems, and the CMM is the best road map for that. | ||||
| Son of "Behavioral clues to organizational process maturity": A framework for understanding organizations | Judah Mogilensky & Stan Rifkin | Software Engineering Process Group (SEPG) Conference, Phoenix, Arizona, February 2002 | ZIP of PowerPoint (33K) | Process Enhancement Partners Inc. & Master Systems Inc. |
| Abstract. Is there a framework-a theory-that can help us organize our informal, unofficial observations about organizations and use them to make better predictions? Do certain observations imply others? Are there any connections-perhaps cause & effect-that can sharpen our observations and our conclusions? Is it possible to understand, and predict, a broad range of organizational behavior (including, but not limited to, behaviors observed as processes mature)? Where might we look for such answers? | ||||
| Why software process innovations are not adopted | Stan Rifkin | IEEE Software, vol. 10, no. 4, pp. 110-112, July/August 2001 | PDF (308K) | Institute of Electrical and Electronics Engineers |
| Abstract. What do these modern, buzzword software methods have in common: eXtreme Programming, Crystal, lean programming, scrum, feature-driven development, adaptive software development, "good enough" software, personal software process/team software process, Rational Unified Process, rapid development, code complete, ...? They all offer something in exchange for a change in work habits, and sometimes in exchange for a "culture" change, too. An important reason organizations do not adopt such methods -that is, do not use them in daily software development-is that what the methods offer is not as important (read "cost-effective") as staying with the status quo. This has nothing to do with inertia or resistance to change. Put more strongly, what these methods offer is irrelevant. Put more diplomatically, what they offer is not strategic for the enterprise. | ||||
| What makes measuring software so hard? | Stan Rifkin | IEEE Software, vol. 10, no. 3, pp. 41-45, May/June 2001 | PDF (212K) | Institute of Electrical and Electronics Engineers |
| Abstract. We often hear that it is difficult to get software measurement into practice. Traditional measurement addresses the decisions that support increased quality, increased programmer productivity, and reduced costs -- key elements for organizations strategically focused on operational excellence. But what if the organization's highest priority isn't operational excellence? This article shows that such organizations have different measurement needs and presents ideas on how to address those needs, thereby making measurement more appealing. The potential mis-fit is universal, so the term "measurement" can be replaced by any of the areas ripe for process improvement. | ||||
| How to select software project macro-estimation tools | Stan Rifkin | IT Metrics Strategies, vol. VI, no. 9, September 2000, pages 13-16 | PDF (228K) | Cutter Consortium |
| Abstract. Over the years I have developed a checklist for selecting automated tools to perform macro software estimates. Here is a description and justification of the list. | ||||
| When the project absolutely must get done: Marrying the organization chart with the precedence diagram | Stan Rifkin | 22nd International Conf on Software Engineering, June 2000, Limerick, Ireland, pp. 588-596 | PDF (109K) | Institute of Electrical and Electronics Engineers |
| Abstract. Very little is new in project planning, but this is! We present a technique to marry the organization chart with a project's task precedence diagram. This permits us to simulate the project at a micro, project-specific level never before achieved. We can perform "what-if" scenarios related to organization structures, the deployment of specific individuals and skills, and the structure of information flow and exception-handling in a project. The tool used, ViteProject, was developed over the last ten years in a Stanford University laboratory, where substantial results have been achieved when applied to design activities other than software. We present our real-world experience with several software projects, where it has improved project visibility and allowed us to rationally optimize projects in a way hitherto impossible. | ||||
| Program comprehension techniques improve software inspections: A case study | Stan Rifkin & Lionel Deimel | 8th International Conf on Program Comprehension, Limerick, Ireland, June 2000, pp. 131-138 | PDF (99K) | Institute of Electrical and Electronics Engineers |
| Abstract. Software inspections are widely regarded as a cost-effective mechanism for removing defects in software, though performing them does not always reduce the number of customer-discovered defects. We present a case study in which an attempt was made to reduce such defects through inspection training that introduced program comprehension ideas. The training was designed to address the problem of understanding the artifact being reviewed, as well as other perceived deficiencies of the inspection process itself. Measures, both formal and informal, suggest that explicit training in program understanding may improve inspection effectiveness. | ||||
| When the project absolutely must get done: Marrying the organization chart with the precedence diagram | Stan Rifkin | IT Metrics Strategies, May 2000, vol. VI, no. 5 | PDF (1M) | Cutter Consortium |
| Abstract. A new tool integrates the project organization chart with the PERT diagram in order to very closely predict the actual completion time of a knowledge- and labor-intensive project, such as software development. Its results are compared with those of traditional software project tools, such as Microsoft Project, that don't take into account communication overhead, delays, waiting, and rework. | ||||
| Discipline of Market Leaders and other impediments to measurement | Stan Rifkin | IT Metrics Strategies, March 2000, vol. VI, no. 3 | PDF (68K) | Cutter Consortium |
| Abstract. We often hear that it is difficult to get software measurement into practice. At least one important reason for this is that traditional software measurement is not aligned with the strategic objectives of the organization. When software measurement is aligned with an organization's market discipline, the implementation is accelerated. | ||||
| Climbing the SEI maturity model makes a difference on software projects | Stan Rifkin | Eleventh International Conference of the Israel Society for Quality, Jerusalem, Israel, November 19-21, 1996 | PDF (102K) | Master Systems Inc. |
| Abstract. Using data from 2,500 completed software projects we illustrate the effects of Software Engineering Institute-style software process maturity on duration, effort (cost), and quality. For example, using the median case, in going from SEI software process maturity level 1 to level 2, a typical business application could save 10 months of development time, 75% of development expense, and 75% of development errors. We illustrate additional SEI levels and give some details of the derivation of the mapping of SEI levels to completed software projects. | ||||
| Measurement in practice | Stan Rifkin & Charles Cox | SEI Tech Report 91-TR-16, July 1991(For some reason this is not on the SEI web site) | PDF (178K) | Software Engineering Institute |
| Abstract. A few organizations have reputations for implementing excellent software measurement practices. A sample of these organizations was surveyed in site visits. Clear patterns of practices emerged and they are reported at a consolidated, "lessons learned" level and in more detailed case studies. | ||||
| Software engineering process group (SEPG) guide | Priscilla Fowler & Stan Rifkin | SEI Tech Report 90-TR-24, September 1990 | PDF (797K) | Software Engineering Institute |
| Abstract. Improving the process of software systems development and maintenance is the most reliable way to improve product quality. This document offers guidance on how to establish a software engineering process group (SEPG) and related software engineering process improvement functions. The process group works with line organizations to improve process quality by helping to assess current status, plan and implement improvements, and transfer technology to facilitate improvement in practice. It has been one of the SEI's most requested technical reports. | ||||