Follow this advice at your own risk, AND, YES, I have seen it work!
AND:
Q: How many BAs does it take to screw in a light bulb?
A: “Tell me MORE about this light bulb.”
If you liked it let us know!
Don’t forget to leave your comments below.
Tell me if you’ve heard this one before – you’re on a project that was thrust on your stakeholder groups from high above. They were insufficiently consulted during the problem definition phase, and they are now questioning everything during implementation. These stakeholders can’t get the project to be outright cancelled, but they can cause it to be ultimately unsuccessful if they don’t commit to putting their time and energy into ensuring that the solution being developed is appropriately used.
Sound familiar? Business Analysts can often be faced with reluctant or even hostile project participants. Sometimes this can be due to lack of sufficient involvement early on, other times it is because they do not see the value in your project. How can you work to overcome these powerful barriers and get your entire stakeholder group to work with the team to successfully implement change?
A few years ago I was working in the education space and faced this challenge. The government had decreed that a change was to occur and that all school boards within the jurisdiction needed to conform within a certain timeframe. As more boards became aware of the change and the impact it would have on their organizations, many naturally questioned why the change was needed. The project team needed an effective way to present the long term value of the change without boring people with facts or figures, or getting into long winded explanations. So we focused on the one common value driver that all the school boards had in common: the student.
We used a short two minute before-and-after video depicting a day in the life of a new student and how the change would positively impact their educational experience. Even seasoned educators had their heartstrings pulled seeing the video; they could immediately empathize with the student and recognize how the situation described was all too common in today’s world. We used this story to introduce nearly every presentation and dialogue we had with our stakeholders for several years, as it helped establish the reason for why the change was necessary and put everyone’s mindset into focusing on the common goal all stakeholders had – providing the best possible education to the student.
Stories can captivate an audience, give them the critical information they need to understand a complex problem in a concise package, and be used to get people with very different backgrounds and goals to relate to shared events and situations. Leveraging stories to engage readers is used in the educational setting to help students process new or challenging experiences. Danielle Lowe, an educator in the state of New York, has observed “story-telling is a timeless teaching tool. Expression through text offers readers of all ages the opportunity to find solutions through the characters and conflicts within a story, and thus within themselves.”
Business Analysts have several opportunities to leverage stories in their work:
You don’t need to have the skills to pen the next great novel to effectively use stories. Focus on the narratives that matter to your audience and think about what compels them to do a better job. For some groups or individuals, it’s the customer that drives their desire for doing good work. For others, it may be recognition or compensation. Like any good story, start off with a problem that needs to be solved and then have your hero (in this case, the proposed solution) save the day. Don’t over exaggerate what the solution can do for the sake of the story, or else you may lose credibility with your audience. Even if the story has a fictional character or problem situation, make sure the benefits the solution is shown to perform are something it can actually do.
Stories can be a powerful and effective tool at conveying information to audiences, and when done well can be used to give people with entrenched viewpoints a chance to look at another perspective without being bombarded with facts or differing opinions. Business Analysts can look to leverage stories to engage and expand the minds of stakeholders in working towards a common goal.
Don’t forget to leave your comments below.
With so much written on trust these days, I thought it might be interesting to provide ten things that you can do that are almost guaranteed to destroy the trust of your project team, peers, and business stakeholders. Busting trust is pretty easy. As Sophocles said, “Trust dies, but mistrust blossoms.” There are lots of ways to destroy trust. For example, we might think of all the ways to build trust and then do the opposite, like being dishonest, or lacking authenticity, or if we are unwilling to communicate bad news. What follows are ten additional ways to bust trust. There are, of course, many more. These are just a few of my favorites.
Don’t forget to leave your comments below.
A2LL – the German social services and unemployment software system was developed over the course of several years by T-Systems – a software department of state telecommunications company – along with ProSoz, a smaller company of about thirty developers located in the town of
The final product was delivered in the last quarter of 2004 and went live on January 1, 2005. The system consisted of the web browser front end, while the back end was based on 16 servers with 4 processors each.
Upon the deployment of the system at several large German cities including
Exhibit 1
|
System Bug Description |
Type of Requirement |
|
If data entered into the form was incomplete (e.g. someone missed one of the many questions) the system automatically deleted the record after about three or four weeks |
Functional |
|
Account numbers that were less than ten digits in length were filled with zeros at the end of the string rather than at the beginning (e.g. 3225223 became 3225223000 instead of 0003225223). |
Functional |
|
System was not capable of producing an “Analysis of Variance” report |
Functional |
|
System was not capable of producing a “Persons Who Received Too Much Money” report |
Functional |
|
System did not include the functionality to deal with the deductions for income from small jobs |
Functional |
|
System could not cope with one-time payments (e.g. schoolchildren purchasing books) |
Functional |
|
System was not registering people properly with their insurance companies |
Functional |
|
System could not properly calculate insurance rates resulting in 25 million euros per month overpayment to the insurance companies |
Functional |
|
Extremely slow response time of the software |
Non-functional |
|
Extremely slow data entry times |
Non-functional |
|
Document printing was incompatible with many local stations |
Non-functional |
As a result of the above-mentioned deficiencies the expert committee appointed by the German government has concluded that the system was inadequate and started considering a new software system, just nine months after A2LL went live.
What are the lessons that can be learned from this project? It looks like the failure of this endeavor is rooted in project team’s inability to extract and document the proper system requirements (both functional and non-functional). After all it is less likely – at least in the author’s humble opinion – that the requirements were captured and included in the Requirements Specifications documentation properly but neglected by the developers.
The inability to properly define the detailed-level scope of IT and software development projects has unfortunately been the root cause of many failures in the hi-tech industry. According to the Standish Group five out of the eight top reasons why projects fail are related to requirements:
Furthermore, between 50-60% of errors in software development originate in the requirements
stage. Rework needed to remove requirements errors can account for as much as 50% of software development projects. And finally, requirements errors are the root cause of 70-85% of rework cost.
Therefore since proper scope definition becomes one of the key factors of project success, this article is dedicated to the extraction and documentation of the functional and non-functional requirements of the system.
Exhibit 2
There is a multitude of software specification templates available in various textbooks, Internet sites and other sources. They include user classes, operating environments, constraints, assumptions, dependencies, various interfaces, etc.
The purpose of this article however, is to concentrate on the two major sections of these documents that usually account for 80-90% of the overall volume – functional and non-functional requirements (see Exhibit 2).
Agility Guide For Functional Requirements
Many of the companies I consult for have been asking me “Well we have switched to the Agile methodology now and we are not sure how to treat our requirements processes now. For example, Do we still have to document them? And what about requirements management?”
My answer to such questions is that regardless of the project management methodology used, traditional waterfall or one of the Agile varieties, sound requirements engineering practice must exist in the project team. Here is a dumbed-down example that I once used during a conversation with a young and overly enthusiastic business analyst:
BA: Do all the rules of traditional waterfall requirements engineering apply on Agile projects?
Me: Let me ask you several questions, if you don’t mind. Pretend you are working on a very conservative waterfall project and have recorded the following statement in the requirements specifications document: “The home page shall load quickly”. What do you think will happen?
BA: The developers will probably insist that I specify the “quick” part; they would probably want to know how fast the page should load.
Me: Perfect! Now imagine you are working on a very Agile project and you write this requirement on the whiteboard or even simply mention it to one of the programmers in the same format. What will his reaction be? Do you think he will find it acceptable?
BA: Hmm … I don’t think so. He will still need to know how fast the page should load.
Me: Aha, so it is the formality of the requirements engineering and not the quality of extensiveness of it that is defined by the agility of the project management methodology!
Before we move one to describing the formality of the requirements approaches let us define three broad project categories first (see Exhibit 3).
Exhibit 3
|
Project Type |
Project Attributes |
|
Agile projects |
|
|
Traditional projects |
|
|
“Something-in-between” projects |
|
So, what are the guidelines for recording functional requirements on various types of projects (see Exhibit 4)?
Exhibit 4
|
Project Type |
Formality Level |
|
Agile projects |
|
|
Traditional projects |
|
|
“Something-in-between” projects |
|
There are several simple rules that have to be followed when recording functional requirements.
Firstly, let’s examine the concise writing rule. This rule consists of several sub-categories. Statements should be short and to the point. They should focus on what the system must do rather than on how it should do it. Also, one of the most difficult aspects to achieve – the statements should not leave any room for interpretation. This task becomes easier to achieve if the writer attempts to record one requirement per statement or paragraph with one verb.
Another good tradition to follow is to consistently use the word “shall” rather than mix “must”, “will”, “might” and “may” to indicate priority and/or create a semantic confusion.
Here is an example of a bad requirement for the readers to analyze and attempt to re-write properly:
Product SKUs entered by the customer will be validated against the SKU master list if possible and the results will be presented in the tabular format to the user
Some of the issues a good requirements expert will notice about this statement are:
A possible improved version of the same requirement may look something like this:
FR 1.3
The ABC system shall validate Product SKUs entered by the user against the SKU master list
If the SKU entered can be located in the SKU master list, the ABC system shall communicate to the user that the product was found and prompt the user to add the product to the shopping basket
If the SKU entered cannot be located in the SKU master list, the ABC system shall communicate to the customer that the product was not found
Exhibits 5-7 list additional attributes of quality requirements.
Exhibit 5
Exhibit 6
Exhibit 7
One of the key issues that I have witnessed on numerous IT and software development projects is over-eagerness of the project stakeholders – both technical team members and customers – to delve into the discussion of the granular design aspects of the final product well before all the functional and non-functional requirements have been defined.
Sometimes the remarks of more experienced team members that the location and the color of the “Submit” button should be postponed until later were very frequently met with the following comments;
“Well, we know this now; why postpone the discussion until later?”
There are two main reasons for separating functionality and design discussions. The first one is that defining the functionality of any software product is a complicated and cumbersome process that has not been fully grasped by many IT professionals. Adding the design-related discussions into the mix complicates things even more and distracts both team members and customers from more important aspects.
Secondly, one should always remember that technical team members (e.g. developers, architects, etc.) typically have a much better understanding of various design options available to the team. Thus it is only logical to expect that developers, architects and UI designers will be able to come up with more efficient and innovative solutions. Furthermore in many cases these solutions could be the ones that the customer did not even know were possible.
Before we explore this topic further, let us look at the respective definitions of the requirement and technical design.
Requirements describe what the customer wants – they communicate business capabilities required to solve business problems or achieve business objectives.
Technical design describes how the requirements will be satisfied and which system components will deliver the new capability.
How can one distinguish between a functional requirement and a design-level solution? One of the easiest ways to weed out design elements in the specification document is to look for phrases like:
“The system (or customer) shall do X by …”
See Exhibit 8 for several examples of design sneaking into requirements.
Exhibit 8
|
The system (or customer) shall do X by … |
Question |
|
… choosing an option from a dropdown menu |
Why does it have to be a dropdown menu necessarily? |
|
… pushing a “Submit” button |
Can it be “Proceed to Checkout” button instead? |
|
… clicking in the checkbox |
Why not radio button? |
What frequently happens during the requirements discussion meetings is that great, cool and incredibly innovative design solutions unexpectedly “pop-up” all over conference rooms. The obvious question at that point of time, “If we are not venturing into design issues right now, what do we do with these cool ideas?”
The solution is to create a “parking lot” in order to capture these “too early to discuss” items in order to revisit them at a proper time of the project. Parking lot can take several forms depending on the complexity and the formality of the project. For example, more Agile project teams may decide to use whiteboards or flipcharts to capture design ideas.
On the other hand it is recommended that more sophisticated projects capture this info in the special section of the System Requirements Specifications document (SRS).
Don’t forget to leave your comments below.
Bibliography
In my previous article, I shared an exercise that helps teams understand how to develop a plan that is manageable and achievable. I call this “Commitment-Based Estimation.” Now I will show how great facilitators can play a role in making their teams super confident about their estimates.
Before we talk about how to do a great job in facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.
I typically find that the Team Lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who will allow the team to own the estimate.
When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to optimize an estimate constantly, then the team won’t feel ownership. This is not how to get a Commitment-Based Estimate.
Similarly, when an Architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.
So who makes the best facilitator for estimation sessions? I’d say look for a person who is:
There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.
Now you may be thinking: Does this mean I can never challenge a team? It does not. What it does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.
For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.
Some of the other approaches that have helped me personally manage some very strong groups include:
In my opinion, too many people take the facilitator role for granted. I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.
Get the whole picture by checking out the other 3 parts of this series –
Part 1 – Part Business Analyst. Part Orchestra Conductor. Part Psychologist – Do you think of yourself as an effective facilitator but unsure how others perceive you? Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently. The differences are subtle. This series is about those subtleties that separate the great facilitators from the mediocre ones.
Part 2 – Check in and the Chair: Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.
Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable.
Don’t forget to leave your comments below.
Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.