Toward Better RE

My career has included managing technical development efforts, managing a team of senior systems and software engineers responsible to implement continuous improvement on major projects for a large IT company, making presentations and providing workshops at industry conferences, and writing articles and books. You may conclude based on the extensive list of issues identified below that it must have been a dreary and difficult experience. On the contrary, it was mostly joyful and very fulfilling. I trust that there is a kernel or two in this article that will enable you to perform your role even more effectively and gain added satisfaction as a result.

Frankly, I’m perplexed that our efforts have not resulted in substantially improved project success rates^[1]. How can it be that these success rates haven’t gotten much better over the past 40 years?

Some of Our Issues

1. We haven’t enabled and conditioned our customers to evolve the real (actual and sufficiently complete) requirements prior to initiating a particular system or software development^[2]. We (customers and engineers alike) do not invest the time to figure out the real needs and to prioritize them before we start other work. We don’t fully define the problems that need to be solved and the opportunities to pursue. Also, we don’t consider related systems enough – both systems that interface with the system under development, and systems that are similar to the system under development that can serve as an analogy from which to learn. Analogies are very useful and we can learn a lot from them. In addition to the tragic and unnecessary waste of resources, think of the frustration we cause customers and users and the fulfillment we deprive from developers. Do we speak up when we should or do we remain quiet, knowing that our work is fraught with problems and issues that eventually will have to be addressed?

2. We haven’t been honest with our customers concerning their perception and assumption that all of their requirements can be known at the start of development and that we will meet all of their “requirements”. This is an educational process requiring leadership and strong inter-personal skills. Also, Project Managers (PM) need to spend a lot more of their time managing expectations (of customers, users, their own managers, their team members – all stakeholders^[3]). This will help greatly because the stakeholders will have added opportunities and information to understand the inevitable problems, issues, and delays. Perhaps a root cause of not being able to do better is not setting the right expectations for requirements and then trying to manage to these unrealistic expectations.

3. We fail to communicate effectively to customers that all requirements are not equal. Clearly, some aspects of the needs are more important than others. We also fail to help the many stakeholder groups to interact and facilitate them to be responsible for figuring out what is most important, next most important, etc. for the total effort – that is, to own (be responsible for) the requirements and for guiding the development effort. What, indeed, is it that the system or software must do?^[4]

4. Related to the previous issue, we haven’t advised (facilitated) our customers in prioritizing requirements and limiting the initial implementation to focus on the perceived highest priority requirements, with the view that the entirety of the effort will be implemented in phases or increments (a – so that we can get the work done and cleaned up (remove defects that we have created and inserted into the project’s work products during our work) prior to deployment, and b - so that we can leverage new learnings and updated technology in subsequent phases). Capers Jones has done magnificent work over many years in advising customers and clients how to remove defects. It’s a disservice to your career not to familiarize yourself with his works and to improve your own approach appropriately. See http://www.spr.com/home/6.html for articles by Caper’s^[5]. He has assembled data relating to the importance of requirements for project success or failure and also the impact of poor requirements on cost escalation.

5. Related, we have allowed our customers to believe that the initial implementation can or should provide the entire system rather than a strategic starting point. Think EVO (evolutionary development) as advocated by industry gurus Tom Gilb^[6], Niels Malotoux^[7], and others. The notion of a strategic starting point is also akin to the Minimum Viable Product (MVP) borrowed from Lean startup practices. ^[8]

6. We have pretended that we can predict (estimate) the effort that is needed to accomplish the development effort. [See Steve McConnell’s Software Estimation: Demystifying the Black Art (Microsoft Press, 2006) that provides an experienced professional’s description of the best practices to apply in developing estimates of the effort required to develop software. Another of his books, Professional Software Development (Addison-Wesley, 2004), is a must read. It includes an overview of the Capability Maturity Model (CMM), an effort to describe the practices that result in project success. Still another, After The Gold Rush: Creating a True Profession of Software Engineering (Microsoft Press, 1999), describes how we might (working in collaboration and continuously improving) evolve into a true profession of software engineering in place of our (still, fifteen years following the book’s publication) current code-and-fix status. Visit http://www.stevemcconnell.com for a real treat.] Some PMs’ wisely designate a management reserve (MR) in their project budget of five or ten percent. Wouldn’t 25% or 50% be more realistic, based on experience? Or perhaps there is a better method for estimation with continuous validation and refinement as we develop a deeper understanding of the task at hand. See Daniel Kahneman‚ Thinking, Fast and Slow. He shows in a very convincing way that intuitive predictions fail most of the time and that small steps are the right way to approach better estimations. Kahneman's treatment of this subject has the potential to change not only how we think, but also how we live our lives.

7. Often there is urgency to start a development effort (not withstanding that many resources typically are wasted during project start-up). Too often we make decisions based on intuition or our best judgment (in other words, “by the seat of our pants”). A much better basis for decision-making is to use data compiled from our own experience using our own previous projects – in other words, Manage by Fact! The things that are measured and tracked and paid attention to by management are the ones that improve. Related to this issue, most often we are willing to start work without incorporating “lessons learned” into our processes. For example, does your organization proactively work to analyze what went wrong in previous development efforts and to apply these lessons in the next development effort? Some developers do take the time to do project post mortems. Unfortunately, too often these lessons learned find their way into shared folders rather than actually being applied to future projects. A better approach is striving for a continuous improvement process that results in changes in our approach. Related is that in most situations, the lessons aren’t learned, rather only observed, and the problems are repeated. It’s not that no one knows how to do it; rather that we choose to proceed without benefit of studying previous efforts, learning, and effectively utilizing resources and methods that are available to help. It’s not that we don’t know or can’t find out what to do; it’s that we don’t do it!

8. Most PMs in my experience do not even attempt to benefit from the experience of other PMs. A root cause of this problem is that organizational cultures don’t expect people to take advantage of knowledge and new learnings. PMs struggle because they are content to proceed without study of and benefit from previous efforts and alternative methods and approaches. For example, I find in my consulting work that most PMs are not familiar with the current project management and technical literature, nor the methods, techniques, information, and guidance available from their peers (Has your organization considered having regular meetings of its PMs to present to each other the lessons learned on their projects?). A caution: Most projects make use of measures and metrics, but often the metrics used do not provide insight into the issues that must be addressed – see How to Save a Failing Project, pp. 4, 19, and 187-196. See also Measures for Excellence: Reliable Software On Time, Within Budget by Lawrence H. Putnam (Yourdon Press, 1992). Another caution: Be mindful to select people for your project staff who are not infected with the “engineer’s syndrome”: “There is only one way to do it and it is my way.” We need staff (leaders) who are experienced in utilizing various methods and who are willing to work with their peers to select the best approaches to utilize in our unique situation. And as noted previously, we need management support for this value – management that fosters and expects continuous improvement.
   Although most PMs sincerely want to do a good job, in my opinion, they allow themselves to be “overwhelmed by alligators”. The truth is that there are successful projects^[9]. A PM must assess her or his effectiveness and work hard (read: take the time and effort) to continuously improve and be successful.

9. We haven’t learned to implement the results of our efforts via a phased approach – to implement portions of the overall effort over a timeline that enables a more informed understanding of what is needed. As we proceed with development, we gain a more informed understanding of the real and evolving needs of our customers and users. By using a phased implementation strategy, we may be able to leverage new learnings in the later phases and more quickly adapt to a changing business climate.

10. Some grasp at methods such as Earned Value^[10] and Agile^[11] without figuring out how to use them effectively. They have heard somewhere that use of such-and-such a technique or method or automated tool is essential or beneficial or the best thing since sliced bread or whatever. So they direct their staff to go buy it or go figure out how to use it or … The experience and counsel of experts including Neal Whitten^[12], Paul Solomon^[13], Capers Jones, Niels Malotoux, Eric Honour^[14], Tom Gilb, Robert Halligan^[15], Steve McConnell, Watts Humphrey, and many others (let alone many other bruised but helpful authors) is marginalized. We need to spend more time and effort digesting the experiences and recommendations of others, and also to encourage PMs with whom we are associated to learn more about (read and study) methods and techniques that will help. Because agile development is difficult and most organizations can't execute it effectively, we need to provide help for more traditional development approaches.

11. Managing technical teams and efforts is challenging^[16]. The development staff typically want to do the right thing and to do things right. It takes a gifted leader to generate empowered teamwork, create collaborative effort, and nurture other leaders. Vitally, managers require strong senior management support if they are to be effective. See “What is Senior Management Commitment?” by Sarah Sheard, available at http://www.ralphyoung.net/articles.html for an excellent treatment of this topic. My suggestion in the event that your manager is not accessible and supportive is to find another opportunity – the sooner, the better. Life is too short and our time and disposition too important than to not be fulfilled in our work. Everyone wants a quick fix that is easy, the silver bullet – trust me, it doesn’t exist!

12. And perhaps last on this list but certainly not least, who are the Requirements Analysts or Engineers (RE) (aka Business Analysts (BA)) on the project? [There are two camps of folks in our profession who are doing the same kind of work but do not communicate much with each other, do not leverage each others’ work, and perhaps often do not even realize that each other exist! One group includes requirements analysts, requirements engineers, requirements managers, systems engineers, and software engineers. These roles have been around a long time and the folks that do these types of work are often members of the International Council on Systems Engineering (INCOSE) (see http://www.incose.org) and the Institute of Electrical and Electronics Engineers (see http://www.ieee.org). The other camp was formed in the last ten to fifteen years; they call themselves “business analysts” (BA). BAs often are employed by companies that have realized that they need a capability to focus on their real needs and to facilitate providing systems and software (information technology), also delivered in the form of software specifications that start with business requirements and the business value that must be delivered through technical assets (software solutions). Business Analysis capability also has a professional organization committed to its value realization and the evolution of its community, the International Institute of Business Analysts [IIBA] [http://www.iiba.org]. See the initial issue of The Requirements Engineering Magazine for its feature article entitled “Five Questions: Learning To Fly” by Howard Podeswa that describes the BA’s role (http://www.spr.com/home/6.html)]. Are the roles, techniques, and deliverables fully understood and agreed to across the team? This function determines the quality of the project definition that will ultimately determine the quality of the project outcomes. In other words, better requirements engineering may well require better or more effective Requirements Engineers!

Solutions

Solutions to the issues identified above are straight-forward but elusive. We have not mastered them. Why not?

“Management” expects miracles and is often lacking key information to think differently. Managers of systems and software development efforts often are not willing to accept the extent of effort (read: choose not to invest the time and money) that is required to do acceptable or (let’s hope) outstanding work. Management is often more interested in winning a contract or undertaking the work than making the effort to figure out what really is required or having the honest conversations with our customers to communicate the full and complete story – that is, the complexity and risks of undertaking a particular project. Customer management is often naïve (misinformed? not honest?) to believe it can get all it (thinks it) wants for the price it demands. Too often in my experience this is an intentional game to get the most out of the supplier. A better approach is to establish a partnering ethic among all stakeholders to support one another in achieving the goals and objectives of the project. See Chapter 3, Partnering for Success, in Project Requirements: A Guide to Best Practices for a description of the Partnering Process. Charles Markert and others are successful in facilitating implementation of this process – see http://www.facilitationcenter.com. Development and customer management are not willing to have honest conversations concerning the effort required to do an excellent job and alternative approaches that will address the age-old problems. It is an invaluable service to our customers to explain that having fewer requirements and less features is in their best interests. Standish Group studies report that only about 20% of the features and functions specified ever get used! (In other words, a very significant portion of the cost and effort of the average system or software development project is wasted. This is data you can and should be discussing with your customers.) Development management fears not winning the work – we would rather win the job than to be forthright concerning that which is needed to perform the work effectively. Customer management often does not understand what problem they are really trying to solve, and what is required to meet stated (let alone real [actual and sufficiently complete]) requirements. We have come full circle back to the message of Dr. W. Edwards Deming, the father of quality: "we must all get into the habit of working every day to get better” – the main thing.

I believe that it is necessary for every requirements engineer to understand and embrace Deming’s management concepts, because this management model provides a framework that enables us to do a better job. Dr. Deming (1900-1993) asserted that American management does not understand variation (faults of the system [common causes] and faults from fleeting events [special causes]). These two categories of faults need to be dealt with differently. Deming’s 14 points provide a theory of management. His seven deadly diseases afflict most organizations and stand in the way of progress. Deming’s thesis is that American management does not enable and empower its work force, which is “only doing its best”. We workers are powerless, lacking the environment to be effective. It’s vital to integrate the essence of Deming’s perspective into your approach. A good way to accomplish this is to digest Mary Walton’s book, The Deming Management Method (A Perigee Book, published by the Berkley Publishing Group, 1986). It provides a good foundation that will enable you to establish and maintain a continuous improvement ethic.

You may choose to pursue certification – for example, the International Requirements Engineering Board (IREB) offers the Certified Professional for Requirements Engineering (CPRE) program (see http://www.ireb.org/en/home.html); INCOSE offers the Certified Systems Engineering Professional (CSEP) program (see http://www.incose.org/educationcareers/certification/); the International Institute of Business Analysts (IIBA) offers the Certified Business Analysis Professional (CBAP) program (see http://www.iiba.org/Certification-Recognition/CBAP-Designation.aspx); and the Project Management Institute (PMI) offers the Project Management Professional (PMP) program (see http://www.pmi.org/Certification.aspx).

We hear a lot about the causes of problems on projects. What are some causes of project success? The table at the bottom of this article lists several causes of success that I have noted being used on projects that were successful, together with an example of its use and a statement of why it helps. I encourage you to consider each of these causes thoughtfully. How could each cause of success contribute to your project, and if shared and adopted widely, your organization? Granted, each of them could require considerable effort to deploy and implement effectively. What might be the return on investment for successful implementation? Perhaps a review of the results of Eric Honour’s work (based on 15 years of research and 94 programs) concerning the return on investment (ROI) of investing in a variety of systems engineering practices (available at http://www.hcode.com/seroi/index.html) will be instructive and might encourage you to explore possibilities.

Engineers of all flavors will benefit from reading, review, and study of The Systems Bible: The Beginner's Guide to Systems Large and Small by John Gall (General Systemantics, 2003) that will help us understand systems.

Conclusion

Now that I think about it, I’ve answered my own question. Our failure to adopt and enact a continuous improvement ethic – the habit of all of us working every day to get better – is a root cause of our inability to achieve significantly improved project success rates.

My suggestions based on dealing with this predicament for some time are the following – please read these slowly and think about each one for a few minutes – how might this apply to your project or your organization? How might you get the ball rolling for your project or your organization? Remember that things won’t change unless you and other leaders cause them to change! And remember, you have to have to “sell” the change to get others onboard! Show the value and you will have followers. Be the change element.

Make things better. Each of us. Every day. Empower others. Create teamwork. Lead. Nurture and mentor other leaders. Learn and apply best practices^[17]. Listen. Learn from others. Read. Write to learn what you know. Acknowledge the efforts of others. Appreciate. Understand. Give. Believe in a higher power. Know that things will work out. Be bold. Believe in yourself. Go for the gold. Enjoy the journey. Value your blessings.

Requirements engineering is about understanding what the customer needs from an IT system in order to best support its business objectives. Making things better with outstanding RE requires all of the actions noted in the previous paragraph.

Next Steps

After re-reading this article, thinking about it, reviewing some of the references, and perhaps doing some writing (to learn what you know), you may want to evolve a self-study program that you decide will further strengthen and improve your abilities to pursue better requirements engineering. I wish you joy and fulfillment on your journey!

“You have brains in your head; you have feet in your shoes. You can steer yourself in any direction you choose.”
Dr. Seuss

Acknowledgements

Sincere appreciation and thanks to Ian Alexander^[18], Rainer Grau^[19], Anne Hartley^[20], Capers Jones, Kim Lauenroth^[21], Sarah Sheard^[22], Kawaljit Singh^[23], and Kimberly Wallace^[24] for providing feedback and suggestions on drafts of this article! The author is responsible for any errors and welcomes feedback.

Cause	An example	Why it helps
Effective leadership. Everyone is a leader. Leaders make the difference.	Requirements engineers who educate customers and users.	Customers and users develop an improved understanding.
Executive support	Management is willing to provide resources ($, time, verbal support)	Management trusts that requirements engineering will help, which empowers requirements engineers
Well-defined goals, objectives, requirements, and measures	Experience shows that these are absent from most projects	The "Project Team" (customers, users, and the development staff) evolve a common understanding
A common vision of the project, its objectives, the approach to be used	A "Partnering Workshop" is used to develop a common vision and trust	All stakeholders become committed to project success and to one another
Commitment	All stakeholders agree on project objectives and to success of the project	Stakeholders agree to support one another with the goal of project success (not personal agendas)
Teamwork	Stakeholders agree to support one another	Problems and issues are resolved collaboratively
Communication: effective, open, honest	Stakeholders share problems, issues, and concerns openly	Honest communication enables the Team to address real issues directly and to resolve them to the best interests of the Project
Expectation of high quality work products	Customer and developer management expect high quality work and work products	Less than high quality work and work products is unacceptable and jeopardizes project success
Trust	Whenever a customer or developer has a concern, it is voiced and resolved	Customers, users, and developers are empowered to support one another
Recognition	The development team has worked extra hours to ensure customer and user satisfaction and is recognized and appreciated for doing so	The members of the development team are energized by being recognized and appreciated
An appropriate staffing model (skill-sets, experience, attitude, etc.)	The "right" resources are provided to the development team to perform the needed work	Management of the development team is sincerely committed to project success
Mentoring and professional development tailored for each member of the project staff	Members of the Project Team are provided appropriate training and experience to perform their roles	Members of the Project Team are competent to perform their roles
Development and documentation of repeatable processes that are tailored and reused	The development team utilizes organizational processes that have been proven effective and are continuously improved	The organization has invested in development and maintenance of work processes that have been proven to be effective
Guidelines to avoid the need for rework	The organization has invested in development of guidelines that have proven to save effort and money	The excessive and unnecessary cost of rework is minimized; Project resources are utilized efficiently and effectively

References

• [1] The Standish Group’s Chaos Manifesto (2011) reports slow improvements in project success rates over the years 2002-2010 (from 34% successful in 2002 to 37% in 2010). The increase in project success rates is related to projects resolved through the agile process. So we are doing better – yet we are far away from good.
• [2] See Chapter 4, Define the Real Customer Needs, in *Effective Requirements Practices* (Addison-Wesley, 2001), for a description of real requirements and a set of recommendations concerning how to evolve them.
• [3] See Chapter 11, Managing External and Internal Expectations, in *How to Save a Failing Project* for a thorough treatment of this critical need.
• [4] Neal Whitten clarified for us in 1998 that we should “Meet Minimum Requirements: Anything More Is Too Much”. PM Network, September 1998: 12(9)19.
• [5] Look for an article by Capers in a future issue of the *RE Magazine*. “Software engineers have a professional and ethical responsibility to point out the hazards of dangerous requirements and to ensure they are safely eliminated.” “The software industry often is not prepared for the magnitude of changing requirements.” “If software engineering is to become a true profession rather than an art form, software engineers have a responsibility to help customers define requirements in a thorough and effective manner. They also have a responsibility to alert clients to the fact that changes in requirements will occur and need to be handled in an effective manner.” “User requirements are never complete and they are often wrong.” “Some clients insist on stuffing extra, superfluous features into software.” See Capers blog and Web site .
• [6] See , specifically *The Evo Standard*, 12 Jan 2013, downloadable from the link to the paper at this Web site. This document is a process description for “doing EVO”. Requirements engineers, requirements managers, and business analysts are well advised to familiarize with Gilb’s works, for example, “What’s Wrong with Requirements Specification?” – Available at . A large number of excellent, thought provoking articles are available and downloadable from Gilb’s Web site.
• [7] See Niels Malotoux, *Evolutionary Project Management Methods*, 4 Dec 2001, available at the downloads link at . Niels, who lives in The Netherlands, provides consultancy in the area of project management – see .
• [8] See for more insight into lean startup and MVP. “It’s just common sense to me to define the smallest component of functioning software that will deliver value, get it out there in front of the customer, get feedback, adapt, and evolve.” (Anne Hartley).
• [9] See my paper, “Doing More with Less: People, Process, Technology”, shared at the Project Executive Forum, Project World Canada, Toronto, May 17, 2011, available on my Web site at the very bottom of the page at that suggests a set of actions that lead to success on projects. See also the 27 January 2011 Gartner paper, How to Increase Your IT Project Success Rate (available on Caper’s Web site at ).
• [10] Millions have been wasted as a result of ineffective implementation of the Earned Value Management (EVM) technique. See Paul Solomon and Ralph Young, *Performance Based Earned Value*, IEEE Computer Society and John Wiley, 2007.
• [11] Some believe that Gilb’s EVO (circa 1989) was the first instantiation of agile. See Agile Project Management, a white paper available at , for a good overall summary of the agile movement. See also issues of the *Agile Record: The Magazine for Agile Developers* available at .
• [12] Neal has been a contributing editor to the Project Management Institute's PM Network magazine for over 15 years. See .
• [13] Paul has devoted his life’s work to the study and implementation of the earned value management method. See .
• [14] Eric is one of the founders of the International Council on Systems Engineering (INCOSE – see - and consider becoming a member if you aren’t already!). Eric has performed ground-breaking research concerning the return on investment (ROI) of systems engineering effort on projects – see .
• [15] See . Robert is an incredible resource and world-wide teacher of systems engineering, requirements analysis, and specification writing.
• [16] *See Powerful Project Leadership* by Wayne Strider (Management Concepts, 2002) for much helpful guidance.
• [17] See Chapter 6, Best Practices for Requirements Development and Management, in *The Requirements Engineering Handbook* (Artech House Publishers, 2004) for a list and explanation of 30 best practices.
• [18] Ian has been involved in requirements engineering for 20 years and has reviewed most requirements-related books and automated tools – see .
• [19] See Rainer’s Chapter, Requirements Engineering in Agile Software Development, in *Software for People *(Springer, 2012) – information available at .
• [20] See for information concerning Anne’s consulting practice – an adaptive, thoughtful, creative, and inspirational business-technology leader for game-changing initiatives and when status quo approaches are not sufficient.
• [21] Kim is Chief of Requirements Engineering at adesso AG, Germany.
• [22] Sarah is a systems engineer currently at the Software Engineering Institute (SEI), Pittsburgh, Pennsylvania USA.
• [23] Kawaljit is Principal Systems Engineer at the MITRE Corporation, McLean, Virginia USA.
• [24] Kim is Senior Project Manager at LL Bean in Freeport, Maine USA.