let's just do it!
One of the hardest parts of any project is to define requirements – in other words, establishing exactly what the client wants and delivering it. Failing to capture the appropriate requirements is the top reason for project failure. In addition, there is always the possibility of “gold plating” occurring during the course of the project. This presentation will suggest guidelines for the project manager to use in establishing with the customer exactly what needs delivering. Also on the other side of the project, the project manager must establish ways to avoid adding features or additional work to the product of the project.
Nike comes to mind concerning a very popular marketing campaign for their athletic shoes. The “Just Do It” tag line on their print and electronic marketing campaigns is a novel approach to selling merchandise. However, this is not an option when it comes to a project. I can safely say that the marketing geniuses of this Nike campaign did not come up with the idea by “just doing it.” There was at least a brainstorming session to come up with the initial concept.
“There is a significant positive relationship between the amount of effort invested in defining the goals of the project and the functional requirements and technical specifications of the product on one hand, and project success on the other, especially in the eyes of the end-user.” (Dvir, Raz, & Shenhar, 2003, p. 94)
“There are lots of problems linked with requirements engineering, including problems in defining the system scope, problems in development or enhance the understanding among the different communities influenced by the development of a given system, and problems in dealing with the changing nature of requirements.” (Al-Hothali, Al-Zubaidi, & Subbarao, 2012, p. 64)
Furthermore, this part of the project is always one of the hardest things to accomplish especially when the client or customer has very little background in the discipline represented by the project manager. Immediately there is a mismatch between the layman and the subject matter expert on terminology, understanding opportunities and constraints of the technologies available and perhaps outright misunderstanding of what can be done to solve the issue at hand or create the product of the project.
“Success in requirements projects depends heavily on the domain knowledge and skills of the people involved, and the effective collaboration between them. After all, few requirements projects succeed without effective problem solving, collaboration, and negotiation.” (Maiden, 2010, p. 46)
“The purpose of this study is to understand how users may serve as knowledge co-producers in the design and development process. We proposed that in the design stage, better design quality can be obtained when users and developers possess knowledge about each other's domain. Furthermore, when common knowledge is inadequate, the relationship between developers and users plays an important role. In the development stage, users should participate in the review process to ensure that the integrated knowledge (system design) is carried out effectively by the developers. Users can help to detect or expose inappropriate designs as early as possible to reduce unnecessary costs. Data collected from 260 IS professionals support all proposed hypotheses.” (Hsu, Lin, Zheng, & Hung, 2012, p. 34)
The other part of this scenario is the advent of misunderstandings between the project manager and members of the team or the team members and the client. With the aforementioned background mismatch the project manager and/or the project team member may take it upon themselves to add features to the product of the project without the knowledge or consent of the client. More often than not this occurs because the project manager or the team member believes they “know better” and believe the changed specifications will enhance the outcomes of the project. Occurrences of “gold plating” might ensue with this type of mismatch.
“…we have a tendency to develop the software we think the customer should want rather than what the customer actually needs.” (Anton & Wells, 2003, p. 46)
And, finally, there is always the issue of changing requirements. Changing requirements, especially in midstream or during the execution phase of a project can cause cost overruns and slipped schedules.
“Software requirement changes are the main risk to software development projects, which usually leads to prolonged schedule and cost overrun.” (Fu, Li, & Chen, 2012, p. 372)
Avenues of Asking
There are many approaches to gathering requirements for a project. One can concentrate on the issues or problems surrounding the project. One can casually enter into conversations with stakeholders on their ideas about the project. However, it helps to have a strategy in place to bring out exactly what the requirements are. Al-Hothali et al. (2012) offered 10 approaches to finding requirements:
- Group Work
- Domain Analysis
- Task Analysis
This author has found that all of these approaches are a combination of Science and Art. Interviews should be structured but with enough open-endedness for discovery. This kind of questioning can occur with individuals or a small group; however, be ready for different dynamics and type of feedback. Group members may feed off each other whereas an individual may not offer as much information.
Brainstorming can lead to many different views of the same problem. This usually takes place with a group of people and there needs to be direction on exactly the premise to brainstorm on. If the issue has been dealt with in previous projects then this tactic may be very limited or a waste of time whereas if the project is an innovation then this may be one of the best ways to find out opportunities and constraints. My experiences have been sessions that are either chaotic or are under control.
The ones that are totally out of control was fostered by having no reasonable limits on what items were germane to the knowledge are or purpose of the project. The sessions that were in control would keep the ideas flowing by using a “parking lot” or a place where some ideas need to be put either because they were not really a part of the current project or they could be helpful in other projects. But the key point is to move on to the issues at hand; yet, keep the discussions open so that new ideas can be considered and the group is engaged. The biggest drawback is where the group senses, from the beginning; that the person in charge already has an idea on how to proceed and their input is not being seriously considered.
Observation can be very helpful to understand a problem. Even doing time and motion studies can be used to understand what is going on and how automation or technology can assist these processes. The only problem is that this can quickly alienate employees who are being “watched.” Being transparent on why you or a team member is in attendance can help alleviate employee concerns about potential reviews on their job performance. The object is to get a realistic view of how a task and process is currently working and how it may be improved. Being up front on the reasons why the observation is taking place will enhance efforts to understand the current routine.
Group work or meetings can be quite helpful as well before entering into the project planning phase. These initial meetings can be helpful in further discovery of the purpose of the project. To keep it on task and on time it is suggested that a clear agenda be created, pre-reads be distributed before the meeting, and each session has a clear goal with a discussion of “next steps” near the end. This can be a series of meetings or even considered a retreat so that the group can concentrate solely on what needs to be done. Off-site is usually better when there will be a lot of distractions for the group members on day-to-day operations. Limiting cell phone or other Internet access devices can also help in concentrating on the tasks at hand.
Questionnaires are helpful especially in a large project in an enterprise environment. However, the questionnaire will have to be vetted carefully so that there are no “leading questions” that give the project manager and team what they think is already the answer. Discovering new views, alternatives to a problem or perhaps there is not problem at all can only enhance the way forward.
The questionnaire should be shared with people who are familiar with this type of elicitation in order to verify the questions as appropriate to the problem or opportunity at hand. Another tactic is to combine knowledge gained from interviews or brainstorming to create the questionnaire. It is a good practice, if time and resources permit, to approach the problem qualitatively (open-ended) at first and then formulate the questionnaire based on that input in order to assign metrics (quantitatively) to the responses. The other challenge is to get the questionnaires answered. Having an event such as a luncheon or other face-to-face get together can facilitate full cooperation on collecting this information.
Laddering falls in line with Ishikawa or Fishbone diagrams to understand the root of the problem. However, the technique can also be used to organize the information in logical order and prioritize issues as well. The technique is a short series of questions to the respondent and then a sorting and follow-up occur in order to elaborate on those issues or dig deeper into the case.
Domain analysis involves looking at documentation on the issue at hand or by looking at previous projects and their lessons learned. This would assume that the organization has mature project management processes in place and an ability to search previous project archives. A good hybrid approach is to do research on previous projects and ask questions of the people who did them or use the information to spur the conversation for the current project.
Task analysis can be another word for work breakdown structure or decomposition of the work to be performed. This can have the extra advantage of gaining buy-in from stakeholders and team members on what the work is and how it needs to be done.
Apprenticing or actually doing the work under the auspices of a practitioner can give further insights into how the work is currently completed. This I would consider before observation, working alongside or actually doing the work clarifies the process and puts the employees at ease. This also gives the employees the chance to show how their work is done and perhaps suggestions on how it could be improved to make it more efficient and effective.
Prototyping or creating an early version of the product of the project for inspection can help as well. In the information systems world it can head off missteps in design by having the end-user try out a part of the computer program. Manufacturing especially in the automotive business use virtual reality (as well as clay modeling) to find out early problems with a vehicle before committing it to production. And of course in construction, a three-dimensional model of the building or facility can help find design problems before building begins.
Not Just One Level
Although anecdotal in nature, experiences in what the client wants have convinced this author that depending on the manager, overseer, boss (insert title of personnel here) is not conducive to finding out what actually needs to be accomplished. Usually there has to be consensus from the employees who will actually use the product during operations on what requirements are and how the problem has to be addressed. One of the best measurements on whether a project has been successful is if the outcomes are being used in the operation of the organization. (See Figure 1.)
This is not to say that top, middle, or area managers do not have relevant information to share on the proposed project. However, bear in mind that these individuals may not have used the current daily operational systems over a long period of time or may have never used them if they were hired in from outside. But there should be due-diligence done to collect this information because there will be issues at every level that may need to be addressed before rolling out the final project. In addition, it is politically astute of the project manager to make sure every level of stakeholder is heard on how the final deliveries should be built, tested, and delivered.
“Furthermore, formal planning is in the hands of the project manager while the development of requirements and specification is dependent on tight cooperation with the end-user.” (Dvir et al., 2003, p. 95)
There is information to be had at every level of the organization. Each viewpoint will give insights into what the project is about and how to approach it. Also, a project manager may find out information from all of these groups regarding either a communications matrix or stakeholder analysis. Valuable insights on what can and cannot work within the culture of the organization can come from this approach.
Ask Them Again
Another practice or miss-step I‘ve seen by fledgling project managers and systems analysts is not being proactive in finding out the requirements. It seems they are hesitant to ask additional questions beyond what was initially asked of the client during formal interviews. Also, they have little or no experience in follow-up questions. There is a need to instill in them the simple concept of who, what, where, why, when, and how (commonly referred to as the five W‘s and H) needs to be addressed in their interviews.
There seems to be concern on the these relatively new participants that they will be looked upon poorly by the client for being perceived as either dull for not getting the information the first time around or that they come off as simply annoying. I usually point out to them that a project manager or a systems analyst looks even duller or absolutely annoying when the product of the project is not what the client wants.
The Match Game
Understanding what approach should be taken comes with experience and education. Some of it is a return to basics and choosing a system development lifecycle process or a business process framework. For example:
“The Requirements Capture stage of the Systems Development life-cycle can be divided into three steps with each of them referring to a specific process within the stage: (a) gather information; (b) examine and assimilate the information (in order to identify requirements); and (c) test whether enough information has been gathered and requirements identified.” (Chatzoglou & Macaulay, 1997, p. 40)
I have added to Chatzoglou and Macaulay's system development life-cycle process with a refine and repeat step if necessary. Refining may be putting it in terms specific to the project team or in layman's terms or both. If there are gaps then this process should be repeated. (Please see Figure 2.)
The project manager needs to select the best way to gather the information. Part of this can be using a business process framework and/or the defined processes of the PMBOK® Guide. Either way additional education needs to take place so that the project manager may choose the best match for the project they're undertaking.
“Education and training should include a discussion of the requirements volatility problem, a presentation of process models with their specific strengths and weaknesses, and a decision framework for selecting the right process model for a project. It is also advisable to let project managers gain experience with different process models, so that their choice is not overly influenced by their previous knowledge and comfort level with a specific model.” (Thakurta & Ahlemann, 2011, p. 6)
In effect the sponsor, project manager, and project team need to step through what has been gathered, understand it, test it, and refine it for clarity. Repeating this process can only help in the understanding and what needs to be done.
Once the groundwork has been laid on what needs to be done, a round of what really is important needs to be done in order to whittle down the list so that a successful product may be realized. This is not to say that all the requirements collected so far are not important but in order to really get to the crux of what needs to be done a sorting of requirement priorities has to occur. This is assuming that there is no consensus that everything recorded needs to be part of the product.
To Prototype or Not to Prototype, That is the Question
Using an agile approach is predicated on using a mock-up or prototype of a system. I have heard arguments about how this practice will prolong development, chew up resources, and endanger the project. A good way to avoid these issues is to go into the prototype with the intent of it being a “working prototype” – in other words, this is going to be the final product once the project is complete. In essence, especially in the information technology field, having weekly testing of what has been completed can only strengthen acceptance of the final product.
Don't be afraid to bring in the customer weekly to test out the product. Perhaps the customer may not want to be this engaged with the project. However, it has to be emphasized that if they want a working system, that meets their needs; this is perhaps one of the best ways to achieve project success.
Include the Team
Getting buy-in and information from the client is very important and this paper has shown some ways of accomplishing this. However, the project manager should not attempt to create a working project plan in isolation. Not only should the project manager engage the client but their own project team.
“Using the project team to develop the PP&C (Project Plan & Control) is a natural process for giving team members active participation in creating the project, a process aimed at developing individual commitment from team members.” (Thomas, Jacques, Adams, & Kihneman-Wooten, 2008, p. 111)
This type of team engagement has proven to be very helpful for successful projects. Project managers who include the team, generate new ideas, streamline processes and achieve team buy-in.
Form a Vision
And finally, upon reflection, a project manager needs to look at the whole project once the requirements are gathered, examined, and refined. The project manager must create a vision of the project.
“We identified four characteristics that a vision should possess: it must be understood; it must be motivational; it must be credible; and it must be both demanding and challenging…Clearly, not all elements need to fully active constantly for project success to be an outcome; however, they should be present at some period during the project's execution and preferably, all present all the time.” (Christenson & Walker, 2004, p. 51)
This is helpful to sustain the running of the project. If the requirements are clear, the team is motivated and challenged and the project is going to add value to the organization, then the chances of success will be close to guaranteed.
Many have heard the term. Some believe it is O.K. Others accept the fact that it's going to happen no matter what and there is nothing they can do about it. “Gold plating” is simply adding more to a project's scope than what was agreed to. Some have said that by doing this the client will be amazed and happy with the enhancements in the final deliverables. The other dimension is that the project manager or a team member may take it upon themselves to add features or improvement to a product because they “know better” or perhaps they are making sure that the product is absolutely perfect even though the perfection will not add any more functionality or added value.
Clearly, this adds to the risk of failure. There is a triple-threat to practicing “gold plating.” It may backfire because the client was unaware of the additions and may find them useless. The project manager may not know that a team member has done something out of scope, which can add costs and break the completion schedule. And finally, it may ruin expectations of the relationship with the client if subsequent projects do not add extra features for free.
The project manager needs to be clear to the client, and the team members what “gold plating” is and that it will not be practiced in this project. This clarity will help control the scope of the project and make it transparent to all the stakeholders.
Requirements that are No Longer Valid
As a project moves forward and these is the process of “Progressive Elaboration” on the requirements it may become clear that some features originally needed are no longer necessary. Or because the nature of the industry, during the project improvements have been made that make some features unnecessary. Again, this relates back to the collection and understanding of requirements.
“Requirements related to standards and laws are the least likely to become obsolete, while inconsistent and ambiguous requirements are the most likely to become obsolete (RQ3). Moreover, requirements originating from domain experts were less likely to become obsolete than requirements originating from customers or (internal) developers.” (Wnuk, Gorschek & Zahda, 2013, p. 937)
Understanding standards or using standards, having clear requirements, and engaging the customer will minimize or mitigate the possible volatility in project requirements.
Here are some parting thoughts from various authors:
“Defining a project is uncovering what needs to be done; ill-defined projects are harder to manage, since the project goal is a moving target. Success is therefore harder to achieve. It is also possible that more successful organizations do a better job of defining their projects and that the association between good definition and success is a product of good project management.” (Besner & Hobbs, 2008, p. S129)
“How much planning is enough? There is no single answer to this question. The right amount of planning depends on the size of the project, the size of the development team, and the purpose of the plan. Furthermore, the timing of planning tasks depends on the organizational environment and the nature of the particular project.” (Chatzoglou & Macaulay, 1997, p. 48)
“Project managers need to devise effective user engagement strategies to facilitate this process; these strategies must be supported by stakeholder training and management commitment.” (Thakurta & Ahlemann, 2011, p. 6)
And finally, Maiden (2010) claimed that finding requirements comes down to trust and suggests the following seven things to achieve this goal:
- Show early on that your requirements techniques work
- Show that you're listening
- Show that you're independent of factions
- Show that you know what you're talking about
- Be transparent
- Keep a trace of everything
- Don't abuse the trust that you gain
Clearly, this can be a highly charged political conundrum for the project manager to overcome. However given due diligence to collecting requirements from all levels of the organization, vetting the requirements, asking follow-up questions, and matching processes to the type of project will assist in guaranteeing success.
Al-Hothali, S., Al-Zubaidi, N., & Subbarao, A. (2012). Requirements elicitation for software projects. International Journal of Computer Science and Information Security, 10(11), 64-71. Retrieved from http://search.proquest.com.library.capella.edu/docview/1270320584?accountid=27965
Anton, A. I., & Wells, D. (2003). Point/counterpoint. IEEE Software, 20(3), 44-47. doi:http://dx.doi.org/10.1109/MS.2003.1196319
Besner, C., & Hobbs, B. (2008). Discriminating contexts and project management best practices on innovative and noninnovative projects. Project Management Journal, 39(S1), S123-S134. doi:10.1002/pmj.20064
Chatzoglou, P., & Macaulay, L. (1997). The importance of human factors in planning the requirements capture stage of a project. International Journal of Project Management, 15(1), 39-53.
Christenson, D., & Walker, D. T. (2004). Understanding the role of “vision” in project success. Project Management Journal, 35(3), 39-52.
Dvir, D., Raz, T., & Shenhar, A. (2003). An empirical analysis of the relationship between project planning and project success. International Journal of Project Management, 21, 89-95.
Fu, Y., Li, M., & Chen, F. (2012). Impact propagation and risk assessment of requirement changes for software development projects based on design structure matrix. International Journal of Project Management, 30(3), 363-373.
Hsu, J., Lin, T., Zheng, G., & Hung, Y. (2012). Users as knowledge co-producers in the information development project. International Journal of Project Management, 30(1), 27-36.
Maiden, N. (2010). Trust me, I‘m an analyst. IEEE Software, 27(1), 46-47. doi:http://dx.doi.org/10.1109/MS.2010.22
Thakurta, R., & Ahlemann, F. (2011). Understanding requirement volatility in software projects. Engineering Management Journal, 23(3), 3-7. Retrieved from http://search.proquest.com.library.capella.edu/docview/904987996?accountid=27965
Thomas, M., Jacques, P. H., Adams, J. R., & Kihneman-Wooten, J. (2008). Developing an effective project: Planning and team building combined. Project Management Journal, 39(4), 105-113. doi:10.1002/pmj.20079
Wnuk, K., Gorschek, T., & Zahda, S. (2013). Obsolete software requirements. Information and Software Technology, 55(6), 921-940. http://dx.doi.org/10.1016/j.infsof.2012.12.001
© 2013, Dr. Loran W. Walker DMIT, PMP
Originally published as a part of 2013 PMI North American Congress Proceedings – New Orleans, Louisiana