Skip to main content

Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

In my previous article, Is it Time for the BA and the PM to Get Hitched? I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the BA/PM for lack of an appropriate title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP4O, for short, to support this new professional.

In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure

The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape

At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.

EffectiveRequirements1.png
Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

  • Linear or Incremental 20% 
  • Iterative or Adaptive 70% 
  • Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together

I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.


Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

 

ITSM Work Sessions: Lessons Learned

Over the last few years I have facilitated several Information Technology Service Management (ITSM) work sessions within the oil and gas and utility industries. The challenge was to build consensus through identifying what is important, making recommendations and decisions, and establish direction that would enable the IT organization to improve processes and services offered to their customers. This article briefly outlines a number of lessons learned that came from our experiences.

An ITSM Work Session should provide the foundation for your organization to create the blueprint to propel IT services and business value forward. In establishing an ITSM initiative the following key groups must be involved:

Strategic: CIO and Directors to establish strategic intent, vision and enterprise objectives

Tactical: Directors and Managers to establish improvement objectives, priorities and program charter

Operational: Managers and Key Stake-holders to establish solution, roadmap, business case and project charters.

Fundamental to any ITSM session, when engaging these groups, is to develop a clear problem definition, defined and approved by the executives or senior steering committee. This is an area in which IT often falls short. The lack of a clear problem definition negatively impacts the tactical and operational levels of the organization, and limits the ability to move forward.

When working with your teams, build an understanding of all the work that is taking place in the IT department right now, and how it fits within the ITSM support and delivery relationship models. Discussion, training and clarity will be required to ensure your people understand the ITSM relationship and delivery model. By engaging people in a defined work exercise, your teams can map out and see how their work aligns with your ITSM program requirements. This is effective in establishing leadership and team buy-in.

Establish a clear understanding of your points of pain (PoPs) and the IT maturity. PoPs can be established through focused brainstorming sessions. Once collected, your PoPs should be looked at from an organizational and process maturity perspective. This is often missed, as IT has a habit of looking only at processes and tools to solve problems. Align your PoPs with the industry maturity model standards (non-existence, chaos, reactive, proactive, service, value). It is important that the content be translated into a service management maturity grid and aligned with the Information Technology Infrastructure Library (ITIL) process categories. Work to obtain various IT teams, customers and business representatives’ perspective on the ITSM organizational and process maturity levels. This builds some reality into the PoPs and maturity levels thinking by dislodging IT from a position of working in isolation.

Build a business case and program plan that can be activated by your people. At this point you are seeking clear recommendations and improvement objectives (what), benefit realization (why), tactical needs (how) and time frame (when) for which to move your organization forward with your ITSM program. This is the foundation for your ITSM program business case and charter that will be divided into project and operational requirements. You will need a solid approved business case and charter to enable you to navigate the challenges that will unfold on your journey and to clearly articulate the streams of work to be completed. There needs to be an executive team or steering committee assigned to provide clear strategic guidance. When forming and using a steering committee, their mandate must be strategic and clear. Tactical, task-based reporting can be left to the project management teams and their need for task-based results and status meetings.

Recognize that ITSM is not an IT tool solution. From a business perspective, IT needs to stop chasing tool solutions, and “flavor-of-the-month quick fixes.” Ultimately, the ITSM program is a business organizational change program that seeks to align IT with the business objectives and requirements, improve processes and change culture in an effort to control or decrease costs, increase productivity and contribute to the bottom-line. ITSM programs need to be effectively operationalized. Therefore change management and communication must be at the forefront.

Work with your teams to have them answer “WIIFM” and “WIIFT” questions (what is in it for me and what is in it for them). Ensure you established the fears, uncertainties and doubts (FUDs). Be prepared to have a long FUDs list. These will need to be acknowledged and managed within the context of the ITSM program and the change management and communications plan. Use your teams and people to establish a communication plan that takes into consideration your target audience and communication needs. Every organization has an approach to communications that may or may not align with their corporate culture. Prepare a clear communications strategy and follow it.

The information in this article is based on feedback obtained during facilitated ITSM work sessions and the work of dedicated IT professionals. Efforts focused on consideration for the strategic, tactical and operational requirements. Ultimately the goal was to improve IT. It can be done. Good luck.

Richard Lannon and BraveWorld Inc. ©2007


Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.

The Debate Over Blending the Roles of the BA and the PM

may15editpic.pngIn the last Business Analyst Times, Bob Wysocki suggested that, in this day and age, the business analyst and the project manager have much in common with major areas of overlap. He pointed out that the skill and competency profiles of the effective BA and the effective PM are virtually identical. He argued that possibly a new role will emerge combining the competency of both. Boy, did that set the fur flying! As a result, we’ve created a dedicated discussion forum for you to participate in. To go there now, click here.

Part two of Bob’s series, Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM, is in this issue and we invite you to read it and react by contributing to what is an ongoing and, at times, heated discussion.

Contributor Richard Lannon brings his experience in facilitating Information Technology Service Management (ITSM) work sessions in the energy sector to helping IT organizations improve processes and services. He stresses the importance of looking at situations from a broad business perspective rather than a narrower IT viewpoint. In his article, ITSM Work Sessions: Lessons Learned, Richard shares the lessons he’s learned over the years and how to put them to work.

Bloggers John Dean and Terry Longo are back. John shares his views on setting up identity systems, while Terry wonders should the BA be part of the IT department or have a broader role within business.

I know you have your own views – I’ve heard some of them on the road. Please share them with other Business Analyst Times readers.

Best Regards,

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

Staying Power

CIO Survey Reveals Most Effective Retention Methods

In the information technology (IT) industry, money talks, but it’s not the only employee-loyalty tool, a new survey shows. When chief information officers (CIOs) were asked to identify the most effective ways to keep IT staff, compensation (27 per cent) topped the list. Providing flexible schedules was close behind, cited by 21 per cent of respondents; another 17 per cent said opportunities for professional development helped to improve retention rates.

The survey was developed by Robert Half Technology, a leading provider of information technology professionals. It was conducted by an independent research firm and is based on telephone interviews with 270 CIOs across Canada.

CIOs were asked, “Which of the following elements have you found most effective at improving IT staff retention?”

Increased compensation…………………………. 27%
Offering flexible schedules………………………. 21%
Professional development or training……… 17%
Telecommuting………………………………………….. 7%
Extra vacation days or time off……………………. 4%
Granting company stock or options…………… 3%
None………………………………………………………….. 1%
Don’t know/other……………………………………… 20%
TOTAL……………………………………………………. 100%

Attractive compensation is a key component of an effective retention program as it shows employees their contributions are valued. A corporate culture that includes work/life balance and training options is also highly valued by IT professionals and is crucial for retaining top performers in a competitive hiring environment.

Effective Retention Programs would include the following components to improve staff retention rates:

Pay competitively. Periodically benchmark employee compensation against industry-standard ranges to ensure your salaries are keeping pace. Robert Half Technology produces an annual Salary Guide with salary ranges for more than 60 IT positions.

Support work/life balance. To prevent teams from burning out, ensure that workloads are realistic. Encourage employees to ask for help when they need it, and consider bringing in project professionals to help during peak periods.

Offer and promote training. Provide IT staff access to the courses and certification programs they need to grow their careers. Make sure employees are aware of professional development opportunities.


Sandra Lavoy

is a vice-president with Robert Half Technology, a leading provider of IT professionals on a project and full-time basis. Robert Half Technology has more than 100 locations in North America, South America, Europe and the Asia-Pacific region, and offers online job search services at www.rht.com. For more information, please call 1-800-793-5533.

Ten Tips for Writing Effective E-mail Messages

  1. Plan the message before you write it. Before writing, ask yourself, “Why am I writing this – what do I want my reader to know and/or do?” When you have the answer, state it at the beginning of your message – this is your main point. 

  1. Organize the information in your message to support the main point. Delete any unnecessary information. Use short paragraphs and bullet points for lists – these make the message easier to read on a screen. 
  2. Identify the right recipients. Don’t send the message to people who don’t need the information. 
  3. Check the content of the message. Make sure there is nothing confidential, personal, inappropriate, or offensive. 
  4. Check the tone of the message. Make sure it doesn’t sound angry, rude, or abrupt. 
  5. Choose the appropriate salutation and closing. Depending on the audience, salutations and closings can be formal, informal, or casual. 
  6. Proofread the message. Fix any grammar, punctuation, and spelling errors. 
  7. Craft a compelling subject line that will tell the reader exactly what the message is about and allow the reader to file and find the message easily later on. 
  8. Make sure attachments are attached. It’s usually best to include attachments as PDFs. 
  9. Include a signature with your contact information. Be sure to include your name, company name, and phone number.

© Copyright 2008 Write It Well


Natasha Terk,

President of Write It Well (www.writeitwell.com), works with a team of skilled instructional designers and trainers to develop and deliver customized on-site and online training solutions about written communications.