Tag: Stakeholder

2 Requirements Tasks You’re Probably Spending Too Much Time On

Written by Angela Wick on August 11, 2016. Posted in Articles.

Can you guess the number one question I get from requirements leaders across the world?

Whether their team is agile, traditional or hybrid, whether their team has 2 members or 250, whether they are creating cutting edge products or maintaining legacy systems, their primary concern remains the same: “How do we get requirements done FASTER?

Despite great intentions, leaders react to this time crunch pressure in a way that actually decreases the speed and quality of their requirements process. The “Get it done faster!” command tends to shift the team’s focus—discussion, collaboration, and true analysis time gets cut short and completing detailed requirements documentation (BRDs, SRSs, use cases, user stories, etc.) takes priority. I see a lot of BA teams struggling with this constant pressure between deadlines and quality.el

In this battle between quality and deadlines, many give into the deadline pressure. So, they jump to documentation without much dialog and analysis and use the document review process to elicit and analyze. You might think this makes sense, especially in well-established organizations, but it will NOT help you speed up your requirements process.

When teams minimize planning, elicitation and analysis, and spend most of their time documenting and reviewing requirements, the process will be long and painful, and teams will miss opportunities to boost value to end users.

So, how is your team doing? What’s the right mix of requirements activities to maximize speed and quality?

Make a pie. Estimate the % time you are spending on these five requirements activities: planning, eliciting, analyzing, documenting and reviewing. Does it look like this?

If your time allocation looks like this, I’m sad to report you are probably doing a great job documenting something that will cause scope changes, rework, and may even result in more problems than value; adding to the ever-growing backlog.

We need to spend less time documenting and reviewing! Documenting and reviewing are low impact forms of communication and collaboration. This means they are not meaningful to the type of thinking requirements work entails. Documenting and reviewing use parts of our cognitive processes that do not help build consensus, do not help connect the dots, and do not inspire critical thinking and progress in our solutions.

So, stakeholders leave meetings drained. Then, hours or days later, attendees think of changes and ideas outside the meeting. They dialog with others and then bring “last-minute” changes to the team. This results in a slower process overall. It takes LONGER to get the same result when teams minimize planning, elicitation, and analysis.

In requirements, we need to shift mindsets and practices to get the critical elicitation and analysis dialog and modeling completed before documenting and reviewing. This will result in quicker meetings and reviews of requirements.

A better mix for all teams (agile, traditional and hybrid) looks something like this:

Documenting and reviewing, when everything else is done right, should take less than 5-10% of total requirements time. We need to guide stakeholders through the process, a process we own as BAs. We must advocate for the importance of planning, elicitation, and analysis and share the risks of reducing or skipping these activities.

Here are a few benefits and risks you can use to help your team or your stakeholders transition to a faster and better requirements:

Requirements planning is about understanding the context, problem, goals, risks to value, and requirements approach. Even agile teams need to plan. It’s the foundation for building the right solution the right way and ensuring the requirements process is meaningful and valuable.

What happens if we reduce or skip it?

The team does not understand the WHY of the process or the problem.
The team cannot anticipate what is coming next.
Team members do not understand how their piece fits in the puzzle or how their piece impacts the rest of the pieces in the puzzle which causes rework.
We over or under engineer the solution.
Progress is chaotic and slow while team members keep circling back to try to understand the items above.
The organization will waste time and money solving the wrong problem.
Trust breaks down between teams.

Requirements elicitation is about getting stakeholders to create a shared understanding of the future state. Elicitation is an iterative process that helps stakeholders move from the big picture down to the finer details. We use models and diagrams to help stakeholders understand processes, workflow, data, user experience, rules/logic/decisions, exceptions, non-functional requirements, etc. Even seemingly straightforward enhancement requests require elicitation to determine if it’s the tip of an iceberg.

What happens if we reduce or skip it?

The team will not understand what the future state looks like, how it delivers value or how it will impact them.
The requirements will have gaps as stakeholders assume their request covers more than stated.
The team will miss innovative ways to bring value to the end users.
The organization will waste time and money fixing the solution/product after implementation.

Requirements analysis helps us understand the impacts of the future state and the people, processes, and technologies are affected. Again all teams, agile and traditional, need to use analysis activities to get the requirements right and build something useful.

What happens if we reduce or skip it?

End users will not be prepared to support or use the solution.
The team will not find requirements gaps, which will generate issues at implementation and require significant time and effort to address.
The team will not maximize the solution value. End-users will not be satisfied with the solution and will request major enhancements or simply avoid using the solution.
The organization will waste time and money building the wrong product/solution.

When planning, elicitation, and analysis are done well, documentation and review are simple and speedy.

The overall goal of planning, elicitation and analysis activities is to create a shared understanding of the various areas of scope, value, and impact. To simplify even further, we get everyone on the same page, so we don’t waste time creating and reviewing irrelevant documentation.

When we have shared understanding it’s easy and quick to put all the pieces into a user story with acceptance criteria, or a requirements document, or a tool. The review/sign-off process becomes quick as well because the team already understands context, scope, value, risk, etc.

How do you minimize time spent on documentation and review? Please share your tips in the comments below.

Snake Oil or Miracle Cure? Is Agile all it’s Cracked up to be?

Written by David Shaffer on February 9, 2016. Posted in Articles. 1 Comment on Snake Oil or Miracle Cure? Is Agile all it’s Cracked up to be?

The Agile Manifesto was born out of frustration by a group of developers who were fed up with how software was being developed. Software development is a learning experience, and no one understands this better than those who are actually writing the code.

Waterfall was a misguided concept that seems reasonable on the surface but does not work in reality. Since software development is a learning process, it is impossible to think of every single requirement up front and have them signed in blood before starting development. We are all familiar with the limitations of Waterfall. However, how many of you have seriously debated or discussed the limitations with Agile?

It seems to me that Agile is too often viewed as the silver bullet cure to all of our delivery issues. Management is constantly under fire from the C-suite to improve the quality, timing, and costs associated with software development. In response, many organizations are diving into Agile with the belief it will cure all of their ills. Billions of dollars are being spent on Agile consultants and software solutions to manage requirements and project plans according to the Agile principles. All of this is being done with the best of intentions. With all of the certification programs, books, blogs, software and training programs devoted to Agile it seems to me that excessive process and red tape is taking over the concept of being “Agile”.
In multiple organizations, I have heard comments such as “We can’t change the questions we ask during standups – if we do we are not Agile!” A number of Agile practitioners have stated to me that if we change the frequency of retrospectives or other Agile ceremonies, then we are no longer “Agile.” This concerns me.

The goal of software development is not to be Agile. The goal is to deliver high-quality software that solves our customer’s business needs. If we achieve this goal, we will meet our revenue targets and grow the business. Being “Agile” is a worthless goal. Customers do not care if a company is Agile or not. They care about the quality of the product.
Do you think Apple would have more customers if they advertised that they were Agile?

This may be coming across as being harsh, but I want to emphasize that there is a risk of losing sight of the ultimate goal when implementing Agile. So if I haven’t ticked you off, and you are still reading you are probably thinking “Ok, then what do we do about it?” We get stuff done; that’s what we do. I am a proponent of my own software delivery methodology I call “Get Stuff Done” or GSD for short. That’s what we all want to do when we get to work; we want to get stuff done. Companies pay us for how well we Get Stuff Done. Many times our processes and red tape get in the way. Think about what you typically complain about at work. I’ll bet that many complaints are about the processes you are being forced to adhere to. Believe me, I’ve had many conversations with colleagues which debate the actual business value of some of the meetings and processes we are forced to follow.

So how do we go about work and just Get Stuff Done? Well, we’ve all heard about the Ice Bucket Challenge so here is a great first step to take.

I encourage you to take the GSD Challenge! For one sprint or iteration, I challenge you to turn off your electronic system for storing requirements and tracking progress. Just say no to using TFS, Jira, Blueprint, Project Server or whatever system you are using. Collocate your team in a conference room. Get yourself some multicolored sticky notes, index cards and Sharpie markers. Write the User Story titles and Acceptance Criteria on the index cards. Prioritize and size each story by writing the priority and story points directly to the card. Tack the cards up on a whiteboard for everyone to see. Have the team write their tasks for each story on the sticky notes. Use a different color for each group (development, test, project management, etc.). Paste the sticky notes next to the story. As each task is completed, move it across the board to indicate it is complete. If you learn something new, and a completed task now requires more work, simply move the sticky note back to in progress. Your team’s progress will be visible to all. Want to know the status of the project? Simply walk into the conference room and take a look. The GSD methodology relies heavily on two skills humans have perfected and used successfully for thousands of years. Bipedal Propulsion Technology (BPT) allows us to use our feet to get up and walk over to colleagues to communicate using Human Voice Technology (HVT). In my opinion, BPT combined with HVT is far superior to email as a communication tool. As a bonus, BPT is good for you! It gets the heart pumping and progress can be tracked using a FitBit or iWatch!

{module ad 300×100 Large mobile}

Collocated teams using GSD don’t have to worry about reserving a conference room for meetings. Calendar conflicts disappear, and email communication significantly decreases. Want to call a meeting using GSD? Simply use your Human Voice Technology to call out to the team “At 1:00 PM we will be having a Sprint Planning meeting!” It’s as simple as that. Don’t worry; with a bit of practice, you will get the hang of using your HVT more often. I understand that email and texting may be seriously eroding your HVT skills but I assure you it’s like riding a bike, it will come back to you. I suggest for maximum success with your GSD challenge you consider providing the following amenities within your collocated room:

A large conference table with network & power connections for the entire team
Additional monitors to allow for dual monitor connections
One or more whiteboards
A projector and projection screen

A little preparation will go a long way to ensuring your GSD challenge is a success. Once the team is collocated, and the user stories are tacked up on the board, you may follow your preferred Agile ceremonies. Standups may still occur at the same time each morning with the team gathered around the whiteboard to comment on their current tasks and what they plan to work on for the day. Standup is a great time for the team to update the board together by moving sticky notes around as needed. I suggest a Retrospective at the end of the GSD challenge to collect feedback from the team on their experience. This should be extremely interesting and provide insight into how the GSD Challenge differs both positively and negatively from your current process.

If you consider attempting the GSD Challenge be prepared for significant pushback from some team members. One of the most common initial complaints about colocation I have heard is “I don’t want to give up my office. I need to think and not be disturbed.” My response is that if your reward for developing software is an office, then you have not actually experienced a fun and rewarding environment. Your reward should be developing quality software in a fun environment that makes millions of dollars, not an office. The team should be allowed to develop their own norms concerning how they will work. For example, when someone truly cannot be disturbed they can wear a special hat or have a funny sign draped over their monitor. Have fun with the challenge and begin working and collaborating as a team. I bet you will be surprised at how little you actually miss your office and the electronic systems most of us rely on to track our progress.

The GSD Challenge is not meant to bash Agile or Scrum. It is to get you actually to think about how you are working and whether the principles you are following actually provide value and allow you to Get Stuff Done. The Agile and Scrum principles are guidelines. They are not laws which must never be violated. Listen to your team and adapt to what works for them as opposed to ensuring that someone can call your group Agile or not. Quality software and making money is the goal. We must never lose sight of that. Thanks for reading and I hope you consider going back to work and getting stuff done!

Leadership Lessons – Problems! Glorious Problems!

Written by Peter de Jager on August 17, 2015. Posted in Articles.

C. K. Chesterton penned a quote that I’m especially fond of, “It isn’t that they can’t see the solution. It’s that they can’t see the problem.” It’s one that constantly reminds me that there is always, without fail, an opportunity lying around somewhere. I just need to find a way to find it.

That wasn’t a typo, I meant to type ‘opportunity’, I didn’t forget that this discussion was about ‘problems’. A problem is an opportunity disguised as a thorn in your assumptions. Fix the problem and you’ve moved yourself forward in some manner, large or small.

Because of how I earn my living, I get lots of feedback – more than a person normally gets in other lines of work – file folders filled to overflowing with feedback. The good feedback is great, I love it (great reading when I’m down in the dumps), it’s what keeps me motivated to keep going. But it’s the negative feedback when people point out a problem, that’s the true treasure. Becoming aware of new problems, if we have the motivation to respond to them, is what motivates us not only to keep going but to start going in a new and improved direction. Problems are always doors to something better.

Organizations don’t like problems. We shy away from them; we shoot messengers who bring them to us, we surround ourselves with 800lb gorilla problems no-one dares talk about. We have terms describing cultural approaches to problems – ‘wilful ignorance’ comes to mind- and we have to legislate whistleblower laws to protect those who make problems public. Organizations let problems fester until there is no other option but to lance them like boils.

When I originally wrote this article, Wikileaks announced that in January 2011 it would release documents disclosing a pile of ‘problems’ in a major US bank. Of course, every ‘major’ bank worried that their ‘problems’ would see the light of day and scrambled to either hide these problems more deeply or hopefully fix the problems as soon as possible.

The irony is that whatever organization got their knuckles soundly rapped by Wikileaks… all of the organizations knew of these issues before Wikileaks, before someone else decided to take action. Organizations ignore problems that obviously need fixing until they are forced to act.

Not all problems fall into the category that Wikileaks exposes. Most of the organizational problems that readers of this article might encounter are more mundane, with less serious consequences. More in the line of “our projects are always delivered late; it takes an inordinate amount of time to get things approved; our meetings are a waste of time; our customer service needs improvement etc.”

Even these can become so much a part of the work environment that we become blind to them, hence my fondness of Chesterton’s quote. We are typically blind to most of the problems around us. We need some way to heighten our awareness of the invisible problems so that we can then, if we choose, correct them. If only we could place a bounty on problems, and in so doing, get everyone looking high and low for them!

Many organizations have some type of suggestion program where they always encourage, and then sometimes reward, employees for bringing new ideas, usually in the form of ‘solutions’, to management’s attention. It’s a step in the right direction of constant improvement, but this strategy contains a hidden flaw. It usually, not always, requires that an individual identifies a problem and then comes up with a viable solution – often on their own. That’s a lot of work for someone who’s already overworked in these tough economic times.

Here’s another idea – instead of requiring a solution – how about just identifying a prominent problem? The individual tagging the problem doesn’t have to solve it, just recognize that it’s worthy of solution. The problem is then passed along to a group of people who love solving problems, people like myself who see all problems as a personal challenge, even as an affront to our sense of order in the universe.

The challenge is still the fact that many problems just hide deep inside the “we’ve always done it that way!” bushes. It takes either a new set of eyes to see these opportunities, or a quickly annoying habit of constantly, incessantly, persistently asking “Why?” about every business process until inefficiencies (if they exist) are exposed.

Borrowing a new set of eyes isn’t too difficult to arrange. Just make it part of the organizational culture to have people from one department work in other departments for short periods of time and report back what they see. The hurdle is for everyone to grasp that the observations, while they will sound like criticisms, are intended – from the very outset – as a way to get better at whatever it is we do for a living.

As to the Why? Why? Why? Why? Why strategy? That requires someone with a peculiar personality. They must have both an analytical mind and a very very good sense of humour. The Why? Why? Why? Why? Why approach – especially about things that everyone takes for granted, takes some getting used to – a sense of humour can take the edge off just a little bit.

Who’s Running the Business?

Written by Aaron Whittenberger on April 20, 2015. Posted in Articles.

Case Studies in Stakeholder Engagement and the Business Analyst Role

I am wondering how many people, after reading that title and my biography, think that I am going to suggest that business analysts should run the business. If you think that is the path that I will take here, you will be sadly disappointed. The Business Analyst’s task is to identify the business problem and get the group of involved stakeholders to collaborate on a solution to that problem. The business analyst is rarely the owner of the solution.

First let me give you some background. I was a developer in the early part of my career and transitioned to a business analyst as the discipline was forming in many companies. The profession of business analysis continues to mature. I have 15 years of consulting experience and have been in many organizations. I have seen how they operate and utilize their business analysts, project managers, architects, developers and quality assurance teams on software development projects to help the business operate more smoothly. In most organizations where I have been, business analysts report to the information technology side of the house. However, I have been in organizations where they reported to the business side or reported to a separate entity within the organization (such as an enterprise PMO), and had business analysts on the business and technical sides of the house. So this article will come from a heavy IT perspective with empathy to the business stakeholder.

One thing I have noticed quite often is that business analysts, project managers and the entire technical team seem to forget that the main duty of business stakeholders is to run the business. You will hear technical team members complain about not being able to get needed time with a key business stakeholder to keep the project going, or that project business sponsors are disengaged. Whereas, the main duty of the technical team is to the project and delivering the solution of that project; let’s remember that the business stakeholder has a different priority. Business stakeholders, in particular subject matter experts (SMEs), are needed on projects to lend their business knowledge and collaborate on a solution. If the technical team was left to design the solution in a silo with no business input, the risk becomes that the solution delivered will be rejected by the business users. The technical team wasted their time delivering a solution that will never be utilized because there was no input, buy-in or ownership from the business. This doesn’t happen in every case, but it would happen at even more alarming rates if the technical team designed the solution without business input. At the same time you can’t get all the business stakeholders as fully dedicated to the project as the technical team is because there would be nobody left to run the business.

This is one of the reasons that the agile approach to software development has taken hold in many companies. By placing one business stakeholder, the product owner, completely dedicated to the IT project, it leaves business management in the engine room to run the business. It is important to the success of the solution that this project owner represents the desires of the business stakeholders well.

So let’s take a look at some case studies in the different organizational structures and the business analyst role in each. Which one is in use in your company? Is it optimal for business success?

Business Analyst reports to Information Technology In this structure the business analyst is viewed as a member of the technical team. From the business stakeholders’ perspective it is difficult to remove the “Us vs. Them” mindset that exists in many organizations because you are part of “Them”. In one organization I was at they talked about a business analyst that literally camped outside a key business stakeholder’s office door all day and still could not get their attention. However, in many organizations this structure works because the business analyst, just like the project manager, is seen as a key member of the project team that helps drive to the needed solution.

Business Analyst reports to the Business Organization

In this structure the “Us vs. Them” mindset works in the opposite direction; where the technical team sees the business analyst as a business stakeholder. I have seen this in two different scenarios; 1) where the business analyst is used as a proxy for other business stakeholders, and 2) where the business analyst is joined on project teams with additional business stakeholders. The perceived value of this structure is to reduce or remove the business stakeholders’ time involvement on software development projects leaving more time to run the business. In the scenario where the business analyst is a proxy for other business stakeholders, the business analyst better be tightly coupled with the business management of the line(s) of business that they are representing or it could spell disaster for the solution delivered. It is the business analyst’s neck that is on the line. The risk in this structure is that the business analyst is not tightly coupled with the technical team to help drive to the best solution to solve the business need.

Business Analyst reports to a Separate Entity within the Organization

This may be the best structure to remove the “Us vs. Them” mindset, as the business analyst is neither “Us” nor “Them”. The business analyst is often seen as a consultant to assist the project team, both business and technical, to come up with the best solution to solve the business problem. The outcome of this structure is often that even though the business analyst is an internal employee, they are seen as an outsider from both sides of the team. This can make it harder to have opinions heard, get recommendations accepted, and drive to consensus. In the situation where it is a PMO that the business analyst reports to, the project manager is likely in the same boat. The side effect of this structure is that it does not reduce the time commitment of the business stakeholders to the project, therefore leaves the question…Who’s Running the Business?

Business Analysts on the Technical Team and Business Analysts in the Business Organization

On rare occasions I witnessed a company going so far as having business analysts on the information technology side and on the business units of the organization. I have seen this structure work efficiently. The ‘business’ business analyst can do the enterprise analysis work to help business management identify business need, develop the business case for a solution to that need, and work the proposal through the project approval process to become an official project. Then there can be a hand-off from the enterprise business analyst to the technical analyst as the project initiates.The technical analyst will see the project through to deliver the expected value to the business. The enterprise business analyst can also serve as the business SME throughout the project to reduce the time commitment of other business stakeholders, thereby leaving someone at the helm to run the business.

So the lessons learned are that the technical team must remember that the business stakeholders’ main duties do not lie with the technical project, as theirs do. When it is difficult to get on the calendars of your business stakeholders, remember they are doing their job. Likewise, as a business stakeholder being asked to participate in a software development project, remember that without your proper level of engagement and dedication to the project the solution delivered may not be the best solution to deliver the greatest value to the organization.Your business team may be stuck with that solution for some time. There is no greater example of the need to collaborate to arrive at the best solution for all concerned.

Don’t forget to leave your comments below.

CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

Written by Marcos Ferrer on January 5, 2015. Posted in Articles. 1 Comment on CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).

Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).

Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.

Simplifying includes breaking concepts down (user friendly means more than a smiley face on screen) with analysis. It works by re-assembling concepts into understandable high quality summaries (models) with synthesis. More than ONE synthesis will be needed. One is for people who will read and follow the complexity. One is for people who won’t be able to pretend they are following unless the words are put into polygon shapes. “I’m visual” is the refrain, but more than four or five polygon shapes quickly reveal that the shapes have “words” anyway, and confusion reigns among the “visual”.

For productivity the experienced analyst understands that working in text can be faster than working in diagrams (at least for analysts that like working in text). An ideal situation is one where a technical writer engages the stakeholders in diagramming simple text while the analyst produces complex text.

Many diagrams are just fancy vague lists. Perfect examples are Visio and PowerPoint “flat” diagrams). As a productivity technique, drawings are easily outpaced by anyone who can create or follow an indented outline.

Here is a sample text “analysis” using the puzzle from the last blog (Everything We Needed to Know We Learned on Sesame Street):

Business Requirements
1. Business Goals / Objectives
  1. We want to increase sales
  2. We want happy customers
  3. We want to get rid of old technology because…
  4. More?
2. Business Needs
3. Capability Gaps
4. Solution Approaches
  1. We want to buy this in ONE software package
  2. We want to outsource all software configuration and maintenance
5. Solution Scope
6. Business Case (what matters, how it matters and why it matters)
Requirements [STATED]
1. Every want is stated only, not modeled, verified or validated.
2. All are vague – unspecific – need improvement
Requirements [ANALYZED / MODELED]
1. No want has been analyzed / modeled
2. Even business objectives are unclear –
Business Analysis Plan
Solution Requirements
1. Functional
  1. We want users to have the freedom to override business rules
  2. We want the system to pick the best approach
  3. We want to capture name and address and contact info everywhere
  4. We don’t want managers interfering with our work (micro-management)
  5. We want to reduce data entry errors
  6. We want direct access to the database
  7. We want users to write their own reports and not wait for IT
  8. We want easier, better scheduling with fewer disruptions
  9. We want large monitors, aluminum cases and wireless keyboards on our PCs
2. Non-Functional / Qualities
  1. We want easy to use
  2. We want a consistent high quality customer experience
  3. We want reliability, maintainability, scalability and no irritability
  4. We will know it when we see it but no sooner
Transition Requirements
1. We must have everything built before release
2. We don’t want to change the work or conditions

We may not agree on whether the above is “correct”. I think we CAN agree that it is not useful, complete or free of conflict. There are unspoken relationships (e.g., relation of “solution requirements” to goals / objectives). There are potential conflicts right next to each other. One example is when stakeholders want direct access to the database vs. fewer data errors.

What can fix this? SYNTHESIS! Are you a business analyst only, or a business synthesist* as well? Creativity isn’t just gums bumping – talk is cheap, watcha got that a project team could follow, that could make sense to those who cannot code ambiguity, confusion or wishful thinking? Most importantly – which statements deserve more focus, and which less? Which statements represent the highest requirements risks? What is missing for effective objectives? What would your process model begin to suggest?

Can any of my readers write a single paragraph describing a workable approach? Can anyone resolve the apparent conflicts by addressing high-level business issues? What do the stakeholders mean and can it be built to the joy of all? Hint: Start by synthesizing “bottom feeding” requirements into “top priority” business needs related to goals and objectives.

And remember – you can’t skip any steps in BA world for true enterprise systems. Pay it now or fail it later. Think of all the BA work (yes, its hard, that’s why stakeholders don’t do it) as leading to a quality groomed backlog. Good process, followed by good interface design followed by quality development is unbeatable.

When we “do what stakeholders want” we are not serving their goals. Not unless they happen to be information systems experts. You might as well try to build a skyscraper for a toddler – “I want the 50th floor to be ALL ice cream” they scream.

Remember to say yes, and to place ice cream fountains everywhere on 50. Make it the centerpiece of the project, so no one will forget which stakeholders insisted. Allow all the stakeholders to pick flavors for prioritization. Above all synthesize the other 99 floors with FAST elevators to 50.

Mo’ later, thanks for reading, don’t get lost in the trees OR the forest.

* Do I have to spell it out for you 🙂 ?

Don’t forget to leave your comments below.