A Call to Action: Vision for Requirements Engineering Revisited
Dr. Ralph Young, CSEP (ralphyoung.net)
“Engineering can provide a life of genuine satisfaction in many ways, especially through ministering in a practical manner to the needs and welfare of mankind.” – Vannevar Bush
“No part of the delivery process is as critical, nor as difficult – because requirements map the human world to the technological world.” – Jim Highsmith

Background

William Heaven requested that I write a sequel to my article that was published in the July 2001 issue of Requirements Quarterly 1 that would provide an assessment ten years later regarding the extent to which my vision has been fulfilled 2. One might argue that great progress has been made. My perspective is that things have improved somewhat – for example, there are new professional organizations that are looking at the issues from a broader perspective; certifications are being offered and earned; research is being done concerning the return on investment of systems and requirements engineering; there have been improvements in the availability of useful and effective automated tools; and there have been other technology advances. These initiatives can improve the understanding of what needs to be done. Professionals including the readers of RQ have been working hard to grow and improve the field. Yet, clearly there are ample opportunities for further progress.

Introduction

My vision for the goals for a contributing requirements engineering field in July 2001 was: 1) satisfied customers, 2) systems and software engineers who are fulfilled by their work, 3) trained and experienced requirements analysts, 4) projects completed on schedule and within budget, and 5) less than 15% rework and less than 10% wasted resources on development projects.

The key points of the article included a set of opportunities for requirements engineers and analysts to improve project success rates; suggestions concerning how requirements engineers can help project managers, customers, and developers; the observations that striving for excellence should be our standard for daily living and that we needed to do things differently; and a challenge to readers to make ever stronger efforts to address requirements-related problems.

Requirements engineering may be defined as an area within the broader fields of systems and software engineering as well as the business analysis profession that has emerged since 2003 that focuses on the requirements process, a full system life-cycle set of actions concerning the necessary attributes of systems. Systems engineering (SE) concerns how to parcel out a huge task into smaller doable pieces so that when they are integrated, they work effectively and a customer and user group find value as a result.

I believe requirements engineering is critical because the requirements provide the basis for all of the other work that is performed on a project. One could argue that if the requirements work is not performed well, there is little chance that a project will be successful. Moreover, we know that the requirements will change while the system is being developed; therefore, we require a methodology that will accommodate requirements changes and new requirements.

Among my goals for this article, the most important is to motivate you to take additional actions to further strengthen and improve the practice of requirements engineering. My hope is that this article will stimulate some ideas and that you will be motivated to take action on them 3.

The Data

One of my mentors emphasizes “Manage by fact”. In other words, get data and use it to guide decision- making. If we look at current data concerning the components of my vision, they are not very encouraging:

Trained and experienced requirements analysts: Total number of CSEPs 4 : 802 (as of November 2011) 5; 25% of the members of IIBA have been business analysts for more than 10 years; 31% have a Masters Degree; 18% have vendor certifications; 10% CBAPs; 10% PMPs; 80% still using MS desktop tools to manage requirements 6.
Projects completed on schedule and within budget: A 1998 Standish Group Report indicated that 26% of projects were successful, 46% were challenged, and 28% failed 7. Today, for information technology (IT), 37% of projects are successful, and we don’t measure business benefit/value/project return on investment (ROI) 8.

Less than 15% rework and less than 10% wasted resources on development projects: Worldwide, we are losing over USD 500 billion per month on IT failure and the problem is getting worse 9.

Note: Data concerning components 1 and 2 of my vision are beyond the scope of this article. However, my view is that things probably haven’ t changed much.

Perhaps underlying the fact that not much has changed is that we have approached change as if the program or project manager or program management office can achieve the needed change without a systems approach involving the entire organization. Current project environments are large, complex adaptive systems – it is very difficult to make a difference in a very interconnected and complex (even competing) landscape.

PMs (as well as other professionals addressed in this article) are ultimately constrained by obsolete management expectations and politics and are not incentivized or encouraged to embrace and model evolving practices. In fact, I would be so bold as to say they are penalized. Another key factor is that the consumers of the work products are not being trained and expected to evolve their ability to consume. Corporate culture allows adoption resistance to prevail and the other excuse is that “we don’t have time to do it right” 10.

Additional Insights

Capers Jones has devoted his professional career to the assessment and improvement of quality. Capers pointed out in 1977 that up to a point, the projects that achieve the lowest defect rates also achieve the shortest schedules, and that most projects can shorten their schedules by focusing on fixing defects earlier 11.

His view is that systems engineering needs added discipline 12.

Professional development in the form of certification programs has increased significantly (Table 1). The data reflect intensive efforts by several international requirements-related professional organizations to work toward improving requirements engineering and business analysis in practice by providing certification programs. The International Council on Systems Engineering (INCOSE) among other professional associations including the Project Management
Institute (PMI), International Institute of Business Analysts (IIBA), and The International Requirements Engineering Board (IREB) have initiated and supported certification programs over the past decade (Certified Systems Engineering Professional [CSEP]), Project Management Professional [PMP]), Certified Business Analysis Professional [CBAP] and
Certification of Competency in Business Analysis (CCBA) 13, and Certified Professional Requirements Engineer [CPRE]) respectively. This is encouraging. We have witnessed the development and publication of INCOSE’ s Systems Engineering Handbook (SEH), PMI’s Project Management Book of Knowledge (PMBOK), and IIBA’s Business Analysis Body of Knowedge (BABOK) and an agile extension to it 14.

INCOSE Systems Engineering Effectiveness Working Group (SEEWG) under the leadership of Joe Elm is performing insightful and useful research concerning the return on investment (ROI) from applying systems engineering on projects 15.The results of this research have shown that projects that apply systems engineering best practices effectively are 40% more likely to succeed than projects that do not. Honour has progressed with similar research over a period of 12 years. In prior work, his SE ROI Project reported that effective SE at a level of approximately 16% of a project’s cost optimizes cost, schedule, and stakeholder success measures 16. In current work, Honour identifies the optimum level of SE total and for each of eight SE activities, including mission/purpose definition, requirements engineering, system archi- tecting, system integration, verification / validation, technical analysis, scope management, and technical management/leadership.

Performance Based Earned Value 17(PBEV) was published in 2007. It was written to advocate a change in industry practice concerning Earned V alue Management (EVM), specifically, basing earned value on the successful completion of quality work products rather than on the amount of effort that has been performed. Paul Solomon has continued to advocate strongly for the needed change 18. Unfortunately, Eleanor Haupt’s hope that was expressed in the Foreword of this book has not been fulfilled 19 – that “Solomon and Young propose a new approach (to EVM) that relies on system engineering standards and maturity models that enhances the value of EVM through more objective assessment of true work performance and product quality…they have not only advanced the practice of EVM; they have achieved what many have only dreamed of: proving the worth of EVM to the technical community”. As a result, millions of dollars continue to be wasted due to deployment and use of ineffective EVM techniques 20. What is required to address effectively the obviously needed change for which a proven solution has been provided? More generally, why is it that improved practices, information, and tools are not used? Why aren’t more effective techniques embraced by practitioners quickly, easily, and enthusiastically? This suggests that an enterprise-wide transformation initiative is required.

Perhaps we are using the wrong mental model for how systems are built. People often refer to it as the “development” process. Perhaps that is too simplistic, and in reality, most of the time it is a “discovery” process instead. “Development” implies that we basically know how everything works, and how to put it together, and it is primarily a problem of assembling the parts, like the construction of a building. “Discovery” implies that there are things that we will uncover as we move forward on the project, and which we could not plan for at the beginning. In fact, the whole “life-cycle” model is based on the traditional model of building a building, which is a development process, not a discovery process 21.

There has been significant improvement in the availability of automated requirements tools over the past decade. A recent issue of The Systems Engineering Newsletter (SyEN) published by Project Performance International (PPI) provides a comprehensive list of requirements tools 22. Another issue of SyEN describes a tool called inteGREAT available from eDev Technologies in Toronto, Canada 23. This tool is inexpensive and offers enhanced collaboration capabilities to help evolve the real requirements 24. Ian Alexander provides descriptive information concerning requirements tools on his website 25. However, in my opinion, leadership, commitment (not just financial), training, and experience in applying automated tools effectively are required to make good use of any tool. There is some evidence that ‘heavy’ automated tools can make things worse when there isn’t a suitable culture in place 26.

Technology

Among the technology improvements we have witnessed in the past decade are vastly improved collaboration capabilities, capability to generate, store and use data at lowered costs, development of ubiquitous networks and internal access, mobility (laptops, cell phones, tablets), security (remote network access), and consumerisation (personal iPhones that enable integration with work lives) 27. Simply put, technology advances should have helped improve the delivery of successful projects – yet we still have an unacceptable number of failed projects a decade later. We still lack the ability in many situations to deploy highly functioning development teams and to deliver the desired results (implement the real requirements, on time, within budget, and in doing so, add value).

From Agile to Evolutionary Development

The Agile Revolution has taken hold worldwide. It has had an impact on expectations, by giving the impression that we can do anything. Or, the other way round, one could assert that our need for instant success has resulted in the agile movement. A long- term result of the agile approach may be a major impact on human factors. For example, over the long term, there may be a loss of knowledge. It seems there is likely to be a convergence over the next five to seven years in the preferred development approach – we will find that agile development is not a panacea. Considering alternative development approaches, it seems likely that evolutionary development (EVO) as advocated by Tom Gilb 28 offers advantage to both customers and developers because the methodology supports discovery, identification, and implementation of the real requirements for a desired capability. Further, it helps us deal with complexity. Although EVO was first described in print in 1988, it is among other rarely used innovations, including risk management planning, JAD sessions, design for change, incremental integration, inspections, and continuous improvement. Most of these innovations have been around for 25 years or more. Why aren’t they being used more extensively? We are confronting a problem of slow diffusion of innovation and best practices to the field (everyday practice). We are on the brink of significant improvement, but we aren’t there yet 29.

Leadership

I and others have identified the need for better leadership both as a root cause of the limited improvement we have experienced and as a critical component of the solution. What is meant by “better leadership”? A leaderly executive will take time to figure out where she or he can weigh in and help. She will identify and apply a set of key principles that enable her to craft and communicate a vision, support staff, delegate, motivate, recognize and acknowledge effort, and hold people accountable for desired results. These principles need to address evolving the real requirements for the project, team building and teamwork, empowerment, process improvement, time to delivery, a development approach that engages customers, a development plan for each member of the staff, and proactive steps to constantly improve communications. The program or project manager (PM) must be given the opportunity and responsibility to manage. She should not be expected to also perform marketing, product development, recruiting, and organizational committee tasks, among many other tasks that PMs are often assigned. We often expect more of organizations; however, organizations are powerless without individual leaders.

Empowerment

During my career, I have had the opportunity to participate in and lead empowered teams. My experience is that an empowered team can accomplish anything it sets out to do. In one instance, it was considered impossible to achieve an objective, but the Team underwent an organizational effectiveness 30process and found that it was able to achieve the objective through effective leadership, commitment, and strong teamwork. One framework that has worked very well in my experience is “partnering” 31. Through use of this technique, we were able to overcome barriers at an important U.S. Federal Government department and to achieve major successes. When project partnering (or “Enterprise Partnering”) is not used, “business as usual” continues. The disappointing thing is that project management curriculums in universities and at PMI have not made partnering a distinct part of learning. They must be assuming it is merely good project management so there is no need to do so. Newsflash: if it is not part of the standard lexicon, it will never survive except through a few dedicated and enlightened individuals.

Possible Opportunities for Stronger Improvement

For us to achieve significant changes, an enterprise- wide transformation initiative is required that takes into account the following areas:

  1. Increased Expectations – of customers, providers, managers, and ourselves. Simply put, the bar is not sufficiently high. Expectations have much to do with results 32. We need to work smarter to create cultures of excellence 33.
  2. Stronger Leadership, Increased Responsibility and Accountability, and Greater Motivation – see Execution: The Discipline of Getting Things Done for help in establishing a set of key leadership principles 34. Neal Whitten’s summary of leadership advice from those who said it best also provides insights into aspects of this root cause 35. Whitten’s “10 Best Practices to Promote the Advancement of Project Management in Your Organization” provides specific suggestions for how to do better 36. Specifically concerning requirements engineering, the ten “Opportunities for Requirements Engineers to Improve Project Success Rates” I provided in the article are still relevant. As I noted then, it is management’s job to provide a motivating work environment in which people can be effective and grow. I describe practical application of many of these aspects and provide an extensive set of references in Effective Requirements Practices.
  3. Stronger and More Effective Teamwork. I devote a lot of emphasis to this in How to Save a Failing Project 37. As previously noted, if you have experienced the blessing of leading or being a member of an “empowered team” (as contrasted with a dysfunctional team), you know the huge difference this makes. We need to embrace more modern approaches to project team leadership and leveraging entire team competency, for example, allowing the lead requirements/business analyst to serve as a partner of the project manager (and that not be interpreted as the PM being insufficient).
  4. Strengthened commitment of individuals, projects, and organizations to continuous improvement. We should all aspire and work smarter to become ever better. An example that comes to mind is the general failure to utilize and leverage so-called “lessons learned” – in my experience, lessons are often observed but rarely learned and acted upon 38.
  5. Stronger senior management commitment. It has been my experience over 46 years of professional activities that it is difficult to accomplish significant efforts on projects and in organizations without senior management commitment. If one can’t gain senior management sponsorship for a significant effort, the probability of successful completion of the effort is limited significantly. Sarah Sheard’ s article explains what senior management commitment is and also how to achieve it 39.
  6. Increased Use of Effective Practices, Information, and Tools that are available. It’s not that we don’t know or can’t find out what to do; it’s that we don’t do it. It’s been my observation over many years that many PMs do not read extensively nor do they take the time and effort to understand, learn, and apply methods, techniques, processes, and tools. In my experience, it is not sufficient for a PM to depend upon staff to provide the leadership to take good advantage of these capabilities. The PM’s understanding, leadership, and commitment are prerequisite to effecting positive change 40.
  7. Investment of additional time and effort up front to evolve the real requirements. The responsibility here is with customers and managers who are obsessed with getting on with “the real work” (coding). Contractors are also responsible to provide informed, honest advice. Individuals are responsible to advocate for improvements. Requirements people need to prevail upon PMs to explain to our customers the value of taking the time and effort to evolve the real requirements before initiating other technical work. Ample evidence is available to make this case 41
  8. Increased honesty and openness in human interaction, and better communication management. Steve Gaffney has devoted his professional career to developing and providing practical ways to address this. He provides seminars that make a difference on projects and in organizations 42.
  9. Reduced rework. Industry data indicate that the average amount of rework performed on the typical project is 45-50% of total effort and that this metric has not changed over the past decade 43. This is an area where the PM and other leaders can foster an environment to chip away at this waste. What approaches might you provide to address in your project or in your organization 44. As noted previously, if you have this on your project or in your organization? lucrative place to initiate improvement is at project startup 45.
  10. Training and implementation of a simple defect prevention initiative/process. Utilize the extensive knowledge of your devoted project staff by sponsoring a brainstorming session to identify major causes of problems. Multi-vote to determine the groups’ sense of their relative importance, impact, and capability to address them. Then brainstorm the group’s suggestions for how to address the high priority causes of problems. Your staff has an enormous capability to help you, if only you let them. Undertaking this process can be an effective team building exercise, in addition to enabling removal of defects earlier 46.
  11. Inculcate requirements engineering and partnering into university and PMI Curricula and make them standalone topics of learning. Without doing this, these techniques will take a backseat and never become mainstream.
  12. Transition of program and project managers’ mind-set from manager to leader.PMs need to transition into the role of a leader by strengthening skills such as visioning, relationship building, influencing, negotiating, creative thinking, innovating, communications management, empowering, building teamwork, acknowledging effort, teaching defect removal techniques, mentoring project performers, employing systems engineering effectively, and setting the tone (and the requirement for) excellence 47.

Needed: A Broader Scope for Requirements Engineering

When I attended the Project World Conference in Orlando, Florida USA in 2006, I became acquainted with another large group that is also working toward improving and utilizing requirements: the Business Analyst Community. The mission of the previously mentioned International Institute of Business Analysis (IIBA) is to develop and maintain standards for the practice of business analysis and for the certification of its practitioners. The IIBA vision is to be the leading worldwide professional association for business analysts. Being an invited speaker, I inquired of my audience of approximately 200 how many would consider themselves aligned with the area of requirements engineering – after explaining what requirements engineering is and what requirements analysts, requirements engineers, and requirements managers do, almost all agreed that the two areas seem very aligned.

Another of our colleagues, Neal Whitten, has been an advocate of project management best practices for many years. In 1998, Neal wrote an article, “Meet Minimum Requirements: Anything More is Too Much” 48. Neil is associated with PMI. As we know, the goals of effective project management are very similar to the objectives of requirements engineering: complete the project successfully, on time, within budget, and add value. Neal maintains a sharp focus on the role of leadership in enabling successful accomplishment of significant efforts 49. See his website for additional insights and resources (www.nealwhittengroup.com).

Kathleen Hass, a member of the IIBA Board of Directors, has a consulting business that specializes in business analysis and complex project management 50. She and other experts have made the case that it is the gap in business analysis and complexity management capabilities and competencies that is the root cause of the inability to deliver successful business solutions 51. She provides a set of building blocks that she feels will enable us to proceed down the “daunting road ahead” and a BA Practice Maturity Model that she feels provides a framework to move forward more effectively. She advocates forming Business Analysis Centers of Excellence (BACOE) to guide the needed improvement efforts. Hass feels that the BA /Requirements Engineer role will change dramatically once we have wide adoption of tools like inteGREAT to manage the fidelity of requirements and keep all requirements artefacts in sync and up to date. “I suspect that BAs spend about 50-80% of their time documenting, managing changes to artefacts, and tracing requirements. Once the tool does that for them, their role will be much more of a change agent, creative leader, innovator, team leader, and influencer.” 52 I am not as confident as is Kitty concerning this happening anytime soon. Hass also points out that IT projects are complex, and we don’t know how to diagnose, manage, and capitalize on complexity. “Complexity breeds creativity if we know how to leverage it.” Hass has developed a Project Complexity Model to diagnose the size, complexity, and risk of a particular project 53

Leveraging Others’ Efforts

Given that we have many disparate professional organizations and groups advocating and working toward improvement in requirements, one of the challenges is the risk of these groups becoming increasingly fragmented. We need to ensure that this doesn’t result in more distinct rival blocks – in other words, the organizations and the individuals in them need to “reach out” to others rather than focus inwardly. Related, from my own writing experience, through contacts with many other authors in several countries, I have observed a need for added inclusion and collaboration across geographical areas – we need to be even more collegial in overcoming the islands of the U.S., Europe, Australia, China, Japan, and on, sharing with and learning from one another.

Toward a Profession of Requirements Engineering

In 1999, Steve McConnell, a leader in defining software engineering’s best practices, authored a book, After The Gold Rush: Creating a True Profession of Software Engineering (ATGR). My note to myself after reading it in March of 2000 was: “A great book. One of the very best in software engineering.” Steve’s comment that “the practices needed to create good software are well established and readily available, but there is a chasm between the average practice and the best” 54 applies to requirements engineering as well. The theme of Steve’s book is how to change. Close to my heart, Steve notes that the most frequent causes of software project failure have to do with requirements problems, which as he notes were prevalent as early as 1969. Another pearl is that “new tools are useful, but not a substitute for clear thinking.” A conclusion is that “despair arises from the fact that some problems have been with us for a quarter century or more and are still common!”

Steve informed me that between publication of ATGR in 1999 and Professional Software Development in 2004, he came to a better understanding of how licensing will be needed – he now believes that only a tiny percentage of software engineers will need to be licensed, and that several of the of the things he suggested in ATGR apply only to those practitioners who need to be licensed 55. Below are the things McConnell suggested in ATGR that we can do to achieve a more mature profession of software engineering that apply equally well to both requirements engineering and systems engineering:

  • Implement a mandatory code of ethics/standard of professional conduct, and meaningful enforcement authority
  • Have a requirement for initial professional education
  • Accreditation
  • Skills development
  • Raise the average level of practice
  • Increase expectations, for example, adopt a code of ethics that imposes higher standards than those normally tolerated in the market place
  • Emphasize social responsibility and duty to behave as members of a disciplined and honourable profession
  • Require a prerequisite of a license prior to admission to practice, e.g., professional engineer
  • Ongoing professional development
  • Participation in professional societies
  • Organizational certification/independent external evaluation of practices
  • Individual certification
  • Continuing education
  • Thoroughly diffusing best practices into industry
  • Management commitment to continuous improvement

Adapting Steve’ s generalization concerning software developers, we can observe that requirements engineers obtain our occupational education from the school of hard knocks; experience can be a good teacher, but it is also slow and expensive. In summary, we are in a position to transform average practice into best practice.

Call to Action

As Neal Whitten so aptly observes, “If you want to make things happen, do not rely on others to lead the way. Leadership is not only about the ability of those around you to lead, it’s also about your ability to lead despite that which is happening around you.” Organizations need leaders who speak for and insist on improvement.

The concerns and suggestions to deal with them that I discussed in my July 2001 article are as valid today as then in order to continue the progress that has been made. Talented and experienced practitioners, academicians, researchers, contractors, customers, developers, vendors, and authors have offered advice concerning how things can be done better. It seems clear that in order to make progress more quickly, individuals and groups need to address the root causes of limited improvement over the past decade that have been identified in this article. During my career, I have experienced highs and lows in the effectiveness and success of the projects in which I have been involved or led. The highly successful efforts were characterized by strong leadership and the other aspects that I have discussed in this article. If we are to achieve higher rates of improvement, we need to act more deliberately in the areas identified. Also, we need enlightened workforce management practices – there is a lot of talk about empowerment and personal initiative, but in reality, this is very much a function of enterprise maturity.

Conclusion

In this article, I have taken a broader perspective concerning my vision for requirements engineering than I did ten years ago. I have proposed opportunities to achieve stronger improvement. Much more significant improvement can be achieved by raising expectations, stronger and more understanding leaders who are able to lead and facilitate the work of others, stronger and more effective teamwork, establishing a culture of continuous improvement, strengthened senior management sponsorship, increased use of effective practices, information, and tools that are available, investment of time and effort to evolve the real requirements before other technical work is initiated, added honesty and openness, communications management, reduced rework, strengthened commitment, bolder actions, deployment and use of a simple defect prevention process, project managers taking the time and effort to learn and apply practices, information, and tools that are available, inculcating requirements engineering and partnering into university and PMI Curricula and making them standalone topics of learning, and transition of program and project managers’ mind-set from manager to leader.

Perhaps our efforts to improve requirements engineering have not paid enough attention to the human elements that cause projects to fail, for example the management support issues noted above. However, it seems that the problem goes deeper and we need to identify more clearly what causes our best intentions to go astray. The field of behavioural economics may provide insights that will help.

John Moore has observed that people deal differently with negative information (mistakes, defects, and errors) than they deal with positive information (successes, accomplishments, and achievements). Since requirements engineering is still primarily a “discovery” process, there will be lots of opportunities for the organization to have to deal with negative information. Perhaps our “development” oriented processes don’t take fully into account this human dynamic – we sometimes try to impose a success and goal-oriented model on a process that will, by nature, involve the uncovering of many problems, mistakes, errors, and misunderstandings. If the organization and its processes cannot deal positively with this negative information, then there is great potential for dysfunction and failure. This is an area that requires more exploration.

Are you ready? In other words, are you willing to rededicate yourself to taking added actions toward the identified opportunities to achieve stronger improvement? For it is only if we individuals (“leaders” [all of us] in Whitten’s context) take actions that the rate of progress will increase. The references provided in this article offer a wealth of ideas, suggestions, recommendations, and advice concerning actions that will help executives, project managers, requirements engineers, and business analysts. One can strengthen continuous improvement by making good use of any of them.

Acknowledgements

Among those who have contributed to this article and stimulated my thinking are Ian Alexander, Anne Hartley, Kitty Hass, Capers Jones, Charles Markert, Joe Matney, Steve McConnell, John Moore, Kent Schneider, Asif Sharif, and Neal Whitten.

Share Button

Notes:

  1. The article is available online at http://www.resg.org.uk/wp-content/uploads/2012/11/RQ24.pdf  pp. 3-6.
  2. In this article, I make generalizations. Also, I suggest that people need to act differently; however, it is not my intent to imply that professionals in the requirements engineering field are less capable than those in other fields. In addition, I have not provided suggested solutions in all cases (although the information in the provided references should be helpful). I do not pretend to have all of the answers. My intent is to reflect thoughtfully on what I have learned with the hope that some of the ideas will be helpful for others to explore and apply, resulting in improvement in the practice of requirements and systems engineering.
  3. A new organization, the Americas Requirements Engineering Association, is dedicated to this goal. See www.a-re-a.org. Tom Love shares his article, “Sorting Out the Terms” there – the article provides useful insights concerning agile, requirements, collaborative, and lessons learned.
  4. All acronyms will be defined.
  5. INCOSE, November 2011.
  6. Forrester/IIBA, 2010.
  7. Standish Group, 1998.
  8. Standish Group, 2010.
  9. Roger Sessions.
  10. Peer review comment contributed by Anne Hartley, AH Consulting LLC – see www.annehartley.com. Ms. Hartley is leading an effort to form a consortium, the Business Analysis Leadership Consortium (BALC) to elevate critical transformation capability.
  11. Applied Software Measurement: Assuring Productivity and Quality, 2nd ed., 1977. 80% of all product defects are inserted in the requirements definition activities as documented in Effective Requirements Practices, p.79.
  12. Personal email to the author, October 23, 2011.
  13. The latter is an intermediate-level certification for professionals who wish to expand their career options and obtain recognition for their ongoing investment in their professional development. See www.theiiba.org
  14. IIBA’s draft for public review of its Agile Extension to the BABOK Guide, November 2011 is available at www.iiba.org
  15. See INCOSE’s Systems Engineering Effectiveness Working Group (SEEWG) website, www.incose.org/practice/techactivities/wg/seewg/. Mr. Elm is performing this research in coordination with the National Defence Industrial Association (NDIA), the IEEE Aerospace and Electronic Systems Society, and Carnegie Mellon University (CMU).
  16. Eric Honour, “Sizing Systems Engineering Activities to Optimize Return on Investment”, Proceedings of the INCOSE International Symposium, Denver, Colorado, USA, 2011. Mr. Honour was awarded the “Founder” award from INCOSE and was the 1997 INCOSE President. See www.honourcode.com.
  17. www.amazon.com/Performance-Based-Earned- Value-Practitioners-Solomon/dp/0471721883
  18. See pb-ev.com/aboutus.aspx; see also “Improving the Quality of Earned V alue Management Information”, journal.thedacs.com, July 2011 V ol 14 No 3.
  19. Past President, Project Management Institute – College of Performance Management, August 2006.
  20. PBEV , p. iv.
  21. Insight provided by peer reviewer John E. Moore.
  22. www.ppi-int.com/newsletter/SyEN-036.php#tools
  23. www.ppi-int.com/newsletter/SyEN-035.php#tools ; see also www.edevtech.com/.
  24. See Effective Requirements Practices, pp. 58-91, for a detailed discussion concerning how to evolve stated requirements into real requirements.
  25. www.easyweb.easynet.co.uk/iany/
  26. Requirements Engineering in Automotive Development – Experiences and Challenges.” IEEE Joint International Conference on Requirements Engineering, 2002.Available at eeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1048 546.
  27. Observations of Jeff Young, Chief Technology Officer, FactSet Research Systems, November 3, 2011. See The Lights in the Tunnel: Automation, Accelerating Technology, and the Economy of the Future by Martin Ford.
  28. See www.gilb.com/Blog.
  29. Steve McConnell, After The Gold Rush, pp. 144- 147. See also Everett M. Rogers’ Diffusion of Innovation and Geoffrey Moore, Crossing the Chasm.
  30. See swat.gis.ksu.edu/documents/org_effectiveness.pdf for a thorough discussion of this powerful technique and references.
  31. See www.facilitationcenter.com/ to learn more about facilitated partnering. Contact Charles Markert to discuss using this powerful technique.
  32. See Roger Connors and Tom Smith, How Did That Happen: Holding People Accountable for Results the Positive Principled Way for powerful insights. The Penguin Group, 2009.
  33. Actually, Steve McConnell provided an insightful description of a recommended pathway forward twelve years ago. See After The Gold Rush: Creating a True Profession of Software Engineering, Microsoft Press, 1999. The second edition of this book has a different title, Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers; Addison-W esley, 2004. See also www.stevemcconnell.com/
  34. Larry Bossidy and Ram Charan, Crown Business Publishers, 2002.
  35. PM Network, October 2010, www.pmi.org
  36. www.nealwhittengroup.com
  37. See Chapter 6.
  38. See Norman L. Kerth, Project Retrospectives: A Handbook for Team Reviews and Ester Derby et al, Agile Retrospectives: Making Good Teams Great for sound advice concerning how to make good advantage of lessons learned.
  39. See Sarah Sheard, “What is Senior Management Commitment?” for an insightful description of this critical role. Available at www.ralphyoung.net/articles.html.
  40. See Project Requirements: A Guide to Best Practices for an extensive array of ideas, suggestions, and recommendations.
  41. Effective Requirements Practices, Chapter 4.
  42. See Steve’s website, www.stevengaffney.com/. Even better, invite Steve to provide a workshop for your project or organization. This will help.
  43. How to Save a Failing Project, pp. 32-33.
  44. See Effective Requirements Practices for ideas and suggestions.
  45. Thomas J. Neff et al, You’re in Charge, Now What?: The 8 Point Plan is a useful resource
  46. A simple defect prevention process is described on pp. 177-180 of How to Save a Failing Project.
  47. A good resource is Emotional Intelligence for Project Managers: The People Skills You Need to Achieve Outstanding Results, by Anthony Mersino, PMP.
  48. PM Network, September 1998:12(9)19, available at http:nealwhittengroup.com/1998/.
  49. See “Words of Wisdom: Leadership Advice from Those Who Said It Best”, PM Network, October 2010, www.pmi.org.
  50. Ms. Hass has authored Managing Complex Projects: A New Model and a series of six books that comprise “The Business Analysis Essential Library”. In addition, her most recent book, The Enterprise Business Analyst: Developing Creative Solutions to Complex Business Problems, aids the transition from a tactical, project-focused role to a creative, innovative role. See www.ManagementConcepts.com/pubs.
  51. See “Planting the Seeds to Grow a Mature Business Analysis Practice,” White Paper published by Kathleen Hass and Associates, www.kathleenhass.com, p. 3. A companion White Paper is “Business Analyst Proficiency: How Capable Do I Need to Be?”
  52. Personal email to the author, November 8, 2011.
  53. See “Living on the Edge: Managing Project Complexity” available at www.ralphyoung.net/articles.html. See also Howard Eisner, Managing Complex Systems: Thinking Outside the Box, John Wiley, 2005.
  54. Microsoft Press, 1999, p. ix.
  55. Personal email to the author, 11/12/2011.

Leave a Reply