Subscribe via RSS Feed

Tag: "requirements definition"

The 3 Great Interrupters: Meetings, Management and Drive-Bys

interruptors-300x199Recently, we’ve introduced Commitment Based Estimation  to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.

It’s 10am and the Requirements Session has Started… Do You Know Where Your Business Team Is?

Requirements-Session-Has-StartedWhen sharing Getting PredictableSM best practices, specifically around requirements definition, a common question that comes from I.T. management,  Business Analysts and Project Managers is:

“How do I get the business to come to the table? How do you get the business folks to commit to the time needed to properly collect requirements for a project?”

 

Most business folks are very busy, but the underlying problem is more than just time management.

Many business users feel it’s a waste of their time. It’s truly annoying to have to tell the “tech folks” requirements. They’re gonna get it wrong anyway.

And you can’t really blame them.

Let’s picture their world:

You’re working 8+ hour days doing your full time business job. You have plenty of regular weekly meetings you go to, some that are a waste of energy.  Now your boss tells you the tech team wants to meet to ask: “How you do your job” or “What features would you like in the new system”.

You show up and as you start sharing your thoughts, they keep suggesting a better way. At times, you hear things like “what you are asking for is very complex – or is undoable”.  A bit frustrating, but you trudge on.

The Requirements Sign-off

Then the business users are asked to read the requirements and sign off.

First off, some of the documents read like a technical manual for a Sears Washer and Dryer explaining how to disassemble the drive motor and replace some fan belt so your washer doesn’t make that whining noise anymore.  The part of the documents that do make sense to you are sort of right – but you’re not sure how much effort to spend to get it 100% perfect.

This might be a little exaggerated, but go ask your business user to read the above paragraph and listen to what they say.  Many will surprise you with their feedback.

Over the next couple of months, the I.T. team asks a few clarifying questions here and there and some of the questions have no resemblance to your original requirement.

When you get the new software, it isn’t what you asked for.  And the technology team is combative. The I.T. team is saying your requirements were wrong and that’s why the system doesn’t work properly.

Surprised?

Hmmm… Why in the world would the business want to experience this?

While  a little exaggerated,  I have to admit that over my career I have heard business users say this.  There is some truth to these remarks and they represent obstacles for our teams.

That said, there  are some simple ways to get the business to check in and truly get passionately involved. Here are some quick ideas to point us in the right direction:

  • First and foremost, Listen.

The joke I share with my technical leads is that “Before we might say ‘no’ to a particular feature, at least listen to their entire request. Then you can say ‘no’”.

And yes – this is intended to point out that all too often, we start compromising a requirement because we know the business better, or their way takes four weeks to do and tweaking the requirement can get it done in one week with an off-the-shelf product. We need to listen to their full need and the “why”.  Then you can be a partner and offer them options.

This brings me to the second suggestion.

  • Give them Options.

Don’t simply tell them the system can’t send the data to all 123 data centers and get responses in under 30 seconds, assimilated in 14 languages and then graphed real time.

Explain to them this one requirement may take two years and 24 people to pull off and that if they would be willing, here are two or three alternatives that may work and would take two months to get completed. Ultimately it’s their budget and their choice on schedule.

They will feel less like something is being “done” to them and more like you are truly trying to help them through this process.

  • Finally, Give them what they asked for and Quickly.

What I mean by this: If they asked for a special screen to do a quick side calculation, and you see they have energy, create a quick mock-up or even a prototype and ask if this is what they had in mind. Make sure you don’t embellish. Give them exactly what they asked for.

If you have a great idea, then show them a second version of the mock-up after you showed them theirs. Let them buy into it.

In an iterative world such as Agile, it is part Agile to quickly turn around a requirement for user feedback.  Even in Waterfall, you can create anything from paper prototypes (see my previous Lo-Fi post) to a wireframe or real code for those scenarios that the user was really passionate about.

Before you know it, you’ll need a bigger conference room for your requirements meetings because all the different business stakeholders will want to come and give you “their” requirements. They won’t trust their colleagues to represent their opinion.

Do you have issues getting the business to come to your requirements sessions? How do you deal with it?

Prototype Technologies are Ruining Your Prototypes

Prototyping-TechnologiesI want to challenge our thinking on how we use prototype technology in our world of software development. Are we using prototypes to help our business users all get on the same page and visualize a solution?  Or are prototypes targeted at our internal team, so they can understand what the resulting system “should look and behave like”?

Prototyping can mean different things to different groups. For purposes of this post, let’s use this definition:

A prototype is an early sample or model built to test a concept or process or to act as a thing to be replicated or learned from.

When I researched this definition, there were some key points that consistently turned up.  They include:

  • A Prototype isn’t the final product.It is designed to test a vision and illustrate a requirement for a final product. For example, if you want to design a car with the gear shift on the left side of the driving wheel, you could create a prototype with only that level of detail. It may not have a horn etc… Just enough to ‘prototype’ the proposed change.
  • A Prototype is used to eliminate ambiguity. In other words, it helps drive a common vision across project participants.  For example:  “Oh… so when you said make it smaller, you really meant tiny or minuscule. I see now”.
  • A Prototype is used to drive feedback. This helps an idea grow before making huge resource or financial commitments.  We might build a working prototype of an Internet Alarm Clock that plays your music stored in the Cloud on the Internet.  It may be fully functioning, but it is a one-off. Its purpose is to gather our initial reactions and generate additional ideas based on the working prototype.
  • Finally, a Prototype might be a Proof-of-Concept. This is used to test the feasibility of an idea and whether the initial vision can actually be delivered with the desired results. This is more of a design based prototype.

Why We Prototype

To summarize, prototypes can be used to:

  • Drive a common vision across stakeholders
  • Confirm our understanding of a desired end-state
  • Provide a forum for feedback among internal stakeholders and external customers.
  • Act as a proof of concept, flushing out the feasibility of an idea

Most prototypes serve one or more of the above the purposes.

These days, there are many tools for prototyping.  Everything from HTML for creating  working-light-weight prototypes for review to wireframe tools such as iRise or Balsamiq.  There are even PowerPoint files with “wireframe templates” in them to build wireframes and mockups using PowerPoint and it’s native tools.

So What’s the Problem?

In spite of the great tools out there, I’ve been in situations where these tools actually get in the way of our goals. They don’t help the business users get to alignment. In fact, prototypes created with these tools can actually drive a “compromise” in their design. Let me explain using an example:

I have three business users working to define a new “quick order” system for their web site.  The Business Analysts spend a couple of hours working with them to collect their vision for the new shopping experience and all the tweaks necessary to take their website to the next level.

We take these requirements and have a designer build a quick prototype so we can make sure this is what they wanted. The final wireframes (built in HTML or another technology) are then emailed around to the business folks for feedback.

Now Volleyball Sets In!

Volleyball starts when one group, in this case the designers, emails information to the users and then the users email back their clarification or changes and the cycle continues.

It’s like each side is sending something over the wall or volleyball net. And, just like in volleyball, if one side drops the ball (or gives up) the other side scores a point.

At this point, the  challenge  is to effectively create a  common vision across multiple stakeholders using email! (Hmmm, I wonder if this is how congress works.)

More often than not, the business gets the prototype to where it’s “Good Enough” and then approves it. They want to get going and hope they can tweak it as it is being developed.

Let’s see how effective this is at achieving our goals for prototyping:

  • Drive a common vision
  • Confirm understanding of a need
  • Provide a forum for feedback
  • Checking feasibility

I would argue that this process is extremely ineffective and delivers inconsistent results.  When someone says this is close enough, are they really saying they feel like we are all on the same page?

If it DID accomplish these goals, then any system that used this approach would have less change requests, less defects and lower overall development cost.

But there is a better way. The Lo-Fi way.

Enter Lo-Fi Prototypes

Here is another way to create and finalize prototypes.  Let’s go back to the meeting where the Business Analysts were collecting requirements.  After they collected the high-level requirements, they use actual post-its that are cut into screen widgets. For example, there are post-its in the shape of data entry fields, list boxes etc. You can even use fan-folded post-its looking like a drop down box.

Now we ask the business users to actually build their screens. Using the post-its, scissors and markers, they create a lo-fidelity prototype. Whenever possible, we print out existing screens, even screens of a competitor, and mark these up with post-its and markers.

The prototype is NOT designed to flush out usability or the end look and  feel. It is used only to enable the business users, as a group, to quickly build their lo-fidelity prototypes and share their vision and intent for the system.

I’ll emphasize that it is CRITICAL they understand that the final system will be a bit different due to design requirements, usability, branding, etc…

This approach is extremely effective and scalable. In fact, I have facilitated a small group of business users using this method to create more than 50 screens and report prototypes in a session.

There are a couple of great benefits using this approach:

  • The stakeholders feel ownership for the prototypes
  • It eliminates ambiguity, frustration and misunderstandings due to volleyball
  • Stakeholders can iterate immediately
  • They work as a group, helping drive alignment which results in less rework
  • Prototypes can be scanned into the requirement documents

At times, we give a few of the more critical lo-fi prototypes to a developer to create a hi-fi prototype (an HTML based prototype that can be interactive) over lunch.  And yes – I said over lunch! The users can then get a real understanding (feedback) on their vision.

So if you really want to use prototypes effectively, forget about all those fancy tools. This down-to-earth, friendly  approach will help you fast path collecting clear requirements and reduce confusion around the real needs and intent of a system, eliminating the pain of volleyball.

As a final note, I believe there is a place for using technology in prototyping. I am a fan of those tools. But I think we have gotten so technology focused, we tend to forget the real goal and use the technology appropriately.

What kind of prototyping tools does your team use? How do you think the post-it approach would go over in your environment?

The Attitude of Estimation

The-Attitude-of-EstimationOver the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.

Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.

To clearly share what I mean by our attitude, let me share a typical estimation experience:

Experiencing the Attitudes of Estimation…

I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.

One person on our team, let’s call her Ann, quickly throws out “This should be about two days”.  Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.

I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.

After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.

One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.

Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.

Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.

Why These Attitudes Make Sense…

I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!

Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.

And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.

Commitment Based Estimates

Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.

When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.

I also don’t want them to pad estimates and not be realistic.

So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?

I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.

In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?

In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.

I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:

  • Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
  • I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day,  three days or five days etc…
  • If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)

The Goal: Consistency

Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.

I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!

As always, please feel free to share this post with anyone you think might benefit.

What Abbott & Costello Can Teach Us About Software Requirements

Whos-On-FirstGrowing up, I used to love watching old black and white comedies, particularly Abbott & Costello.  If you’ve never seen their classic “Who’s on First”, you can find it right here on YouTube.  Feel free to watch it now (but be sure to come back)!

Briefly, this comedy skit is about Abbott explaining to Costello the names of the players on their baseball team.  The names of the players include “Who” playing 1st base, “What” playing 2nd base and “I Don’t Know” playing 3rd base.  Costello wants to know what the players’ names are, so he would ask “Who’s playing first base?” and Abbott would proudly respond “Exactly”.  A frustrated Costello asks “What is the name of the person on first base” and now Costello would reply “No, he plays second”.

If you have never heard the routine, you must listen to it to appreciate it. The link above should help. But I digress.

“Who’s on First” can teach us a great deal about the pitfalls of collecting requirements:

We can have two business users reviewing the same requirements document, each thinking it says something very different. It gets worse. In the real world of requirements, this confusion isn’t limited to two individuals. It spans the entire team, including the business analysts, testing team and developers.

The obvious difference between the “Who’s on First” routine and real life requirements, is that Abbott & Costello know they are having a communication problem.

In the real world, the situation is actually much more challenging.

The “Spellchecker”

Let me share with you an actual “Who’s on First” example that happens almost every time we collect requirements.  I call this the “Spellchecker” (and this is totally fiction, made up for illustrating my point).

Let’s pretend we need to add Spellchecker capability to our mobile application. We send out an RFP to various firms. In this example let’s say we send it out to Apple and Microsoft.

Apple responds and says they need two people working for two weeks.
Microsoft responds that they need four people working for six weeks.

We wonder: how does one company’s estimate result in four person-weeks while another is twenty-four person-weeks?  Did Microsoft pad their estimate? Or did Apple simply not spend the right energy on estimating and they pulled a number out of the air?

So we ask Apple: “What are the two people going to do for two weeks”? They respond that they will build two screens and one engine. The two screens will include the screen that shows you replacement words and a confirmation screen.  The engine is the actual “Spellchecker”.

Seems reasonable.

Then, we ask Microsoft: “What are four people going to do for six weeks”? They respond that they will be working on eleven screens and three engines and possibly some APIs.

Hmmm. We pause and ask: What are these eleven screens going to be used for? They explain the same two screens and engine that Apple discussed.

But they also have screens that allow you to add and maintain a list of “custom words” for your personal dictionary.  Further, they have screens that allow you to plug in a proprietary dictionary such as a medical dictionary or a special language.  That is how they got to eleven screens.

WOW! I never thought of that detail. Now I have to think of which version of the “Spellchecker” I really want.

If I want the two-screen version, I have to ask Microsoft to change their assumptions and re-estimate.  If I want the eleven-screen version, I have to provide the clarity to Apple and ask for their re-estimate. Most likely, I may want something in between. Maybe a seven screen version. I want the “custom dictionary of personal words, but NOT the proprietary dictionaries”. So I clarify and ask them both to submit a re-estimate.

Unlike Abbott & Costello who knew they weren’t communicating, in  the real world, we usually don’t catch our “Spellcheckers”. The BAs write up the requirements and the developers deliver the code.  We all think:  How difficult can it be to understand? After all, the business folks said they just want a Spellchecker! How much more straightforward can you get?

And later, when we deliver a solution that missed the point, the business will hold the BA and developer accountable! I mean it’s as simple as “Who’s on First”!

Taking the First Step

After sharing the “Spellchecker” story with the teams I work with, we actually use the word “Spellchecker” in our every day conversations to help uncover ambiguities and assumptions. It’s sort of a “keyword” around here.

Say we are discussing how we  can’t put the next release of our software into production until we fix all of the defects that our top executive just finished screaming at us about. The developers estimate that this can take two to three months.

Our manager responds that we are estimating out of fear and these defects can be squashed in weeks. There is no way he is telling the executives that they have to wait another “three months”!

Then, someone pop-ups in the heat of this conversation and says:

Time-out.  Do we have a “Spellchecker”? When you say fix “All the Defects”, we see there are over 50 defects in the system and we can’t imagine fixing all of those with four developers in a matter of two weeks.

Our manager responds:

50? No way!  We only need the Severity 1 defects fixed. There are only four of those defects.

And the team responds:

That makes a big difference. Yes we should be able to get that done in a couple of weeks. But are you sure that the Executives agree to only work on the Severity 1 defects?  It’s a Spellchecker to them too!

The Benefit of Acknowledging Spellcheckers

Not only do the teams I work with use the word Spellchecker to call out ambiguities, I have clients that have adopted this practice, calling out situations where they question whether  “are we really talking about the same thing”. (In fact, the spellchecker concept is so useful, even my family has adopted using it).

There will always be areas that slip in between the cracks. You can’t catch every Spellchecker. However, the real benefit of acknowledging Spellcheckers is the fact that everyone acknowledges that unintentional Spellcheckers, not individuals, can be obstacles to a team’s effectiveness.

More important, Spellcheckers often point to a two-sided misunderstanding.  Many times, when you uncover a spellchecker in requirements, the business person will say: I didn’t even think about that. I am not sure what I meant.

I’ll add one more example: When a business user identifies a defect in the software we delivered, we argue that this is an enhancement and not a defect. This is usually a Spellchecker in action and we are both right (or wrong)!

Now, Who Did You Say Is On First?

My suggestion is to introduce the concept of Spellcheckers to your team and ask everyone to speak up when they see Spellcheckers.  Share this with your business folks, management, and everyone else involved on the project. When you identify a Spellchecker, everyone can agree that no individual is at fault. It is simply a challenge in every day communication.

I’ll leave you with a final link.  I recently came across another short video that is a modern day technical version of “Who’s on First”.  I hope you enjoy this as much as I did. I especially like the punch line at the end.

Please comment and let me know about how Spellcheckers create confusion in your world and any other insights on the topic.

If you think others in your network or organization would benefit from learning about Spellcheckers, feel free to share this post using the tools below.

Photo Credit: Purple Slog

Iteration Zero: Reduce Risk Before You Begin the Project

Reduce Software Project Risk Before Construction Starts

Sunglasses-and-RoadmapLast week we talked about the level of planning required to ensure that a journey (whether a travel adventure or a software project) be enjoyable, problem free and capable of delivering better results.

In the first stage of planning for our journey, we identified where we wanted to go and how we thought we’d get there. In software development, this can be thought of as business definition and understanding the business objectives. The second stage of preparation for our fictional journey — studying a detailed map and the purchase of travel gear — can be thought of as Iteration Zero.  This is where the team’s virtual assembly line is prepared. Finally, the third stage of swimming and running is the construction phase.

Iteration Zero sets up the groundwork for construction by implementing the reusable patterns and components in the application architecture and preparing the environment for a development team to be effective. This phase helps to remove the traditional Just-In-Time environment setup that often occurs in the construction phase. By adding an Iteration Zero, you are essentially allowing for time to be utilized more effectively and predictably during the construction phase.

One perception about the phrase “Iteration Zero” is that it implies an agile style of development. This is not necessarily so. The practices in “Iteration Zero” have been used successfully with several different development methodologies.

One of the major dependencies for an effective Iteration Zero is awareness of the success criteria of the project defined and agreed to by the business. They also need to be understood by the technical team(s) before the Iteration.

Creating a Forum to Ask Questions and Learn

One of the most important elements for executing Iteration Zero is the Workshop. The Workshop allows the team to see how the software is going to be developed from a process perspective. Additionally, it helps the team become familiar with the technologies, components and patterns implemented and added to the code solution. This begins the process of the team becoming immersed in the construction process.

In order for the development and quality teams to be effective in Iteration 1, the Business Analyst should begin creating the Business Rules Documentation. Iteration Zero provides them with a jump start from both the development team and the quality team.

Iteration Zero can also be used to identify risky technical aspects of the system. These risky elements should be studied to form a mitigation plan (during Iteration Zero) to learn as much as possible, as early as possible.

Hit the Ground Running

Although there are ways to prevent a project catastrophe, most of us have still seen at least one project land in the dumpster for a myriad of possible reasons. While there are risky elements outside of delivery that can hurt a project, adding and enforcing Iteration Zero is a great way to make sure your next journey goes faster, behaves more predictably, and adds more value to the business.

How is your team using Iteration Zero?

Photo Credit: Thomas Beck Photo

Forrester Webinar Uncovers the Ugly Truth About Project Failure

This afternoon, I participated in a webinar with Forrester Research (full recording embedded below).  The turnout was great and, as expected, the energy on this particular topic was high.  After all, who among us hasn’t lived through the pain of project failure?

We spent an hour with Forrester Analyst, Mary Gerush, who shared some valuable insight on why requirements definition is the key to avoiding project failure. Says Mary, requirements “must be a collaborative, business driven approach” in order to get the business what it needs.

Some of Mary’s key points included:

  1. Finding and fixing a software problem after delivery is often 100x more expensive than finding and fixing it during the requirements and design phase.
  2. Slide07-300x225In addition to the financial impact of project failure, the damage done to the entire organization can be brutal:  End users go elsewhere. The trust of your business partners evaporates.  The development team loses confidence.
  3. Business and technology teams struggle to work together for many reasons: Economic challenges; consumer insistence on instant satisfaction; business and technology silos; multi-channel product distribution; third party partnerships; and new integrated environments.  Now we have many stakeholders with varying motivation and needs … often at odds with each other.
  4. Unfortunately, these varied groups of stakeholders may or may not know how to tell you what they need. There’s often a gap between what the stakeholder wants … what the project team has to understand … and what really has to be done.
  5. Business-Technology (BT) partnerships can change this game. A BT approach requires business stakeholders to take ownership of requirements and make the time commitment to be proactively involved.
  6. Business success is all that matters.  Instead of measuring business success in terms of on time/on budget, we should measure it by benefits realization, customer satisfaction and ROI.
  7. Slide23-300x225The BT Requirements life cycle starts by establishing a clear business vision and measuring success in terms of business impact.
  8. Success means recognizing that requirements live before, during and after a project.

When it comes to requirements, I continually emphasize the importance of creating a shared vision of success between the business stakeholders first, and then between business and IT.  When all the business stakeholders agree to exactly what they need, it makes it easier for the development team to deliver it!

We heard in the webinar that in order for the business to get what it wants, it must commit the time to collaborate on the business issues. One of my favorite parts of a project is when the business perspective on success criteria begins to emerge – without geek talk or specifications. This is when everyone involved feels totally confident for the first time that a common vision of success is achievable and will get clearly communicated to the development team.

Within the next couple days, we’ll post a recording of the webinar here. So, come back for a review and feel free to pass it along to your colleagues.

How about your team? How do you keep your business stakeholders committed and engaged in the requirements process?

View the webinar in it’s entirety: