Skip to main content

Bad-Ass BA on Steroids

Written by Cecilie Hoffman on . Posted in Articles. 1 Comment on Bad-Ass BA on Steroids

Busting a Requirements Document Planning Myth

Writing a requirements document – where does the time really go?

Have you noticed that requirements documents always take longer than expected to complete? Even when we follow the best practice of planning the activities, the reality is that even the most experienced of us blow our schedule. But why? There’s a perception that the BA is “in control” of all the events, and in control of the document’s progress from start to finish. We know that’s a myth. Let’s be bad-ass BAs and bust the myth.

You probably already know about the best practice of preparing a requirements work plan for your requirements document. A requirements work plan is essentially a mini-project plan that has one deliverable, the completed requirements document. By identifying the tasks needed to complete your requirements document, you can estimate the time needed to produce the deliverable. Moreover, you can negotiate the tasks from an objective basis instead of waving your hands and asserting that there’s no way you can get this done in two weeks.

To frame our requirements document authoring project, let’s establish a starting point and an end point, and examine the events in between. The starting point is the moment you receive the request from your manager to prepare the requirements document. For the sake of argument, let’s assume that the manager provides some level of input documentation which outlines the problem that the project is addressing, for example a business case or project charter. The end point is when you deliver the approved requirements document. So, in a typical work plan, you would identify tasks like these:

  • Interview stakeholders and SMEs to elicit customer “needs” and explicit success criteria
  • Prepare the graphical representations for the document, e.g., a SIPOC, or another context-setting diagram that gets everyone on the same page, so to speak, and the “as is” and the “to be” diagrams.
  • Prepare the high-level Use Cases, process maps,
  • Prepare the first draft of the requirements document, which includes Project Scope, assumptions, risks, the diagrams, the use cases, and oh yes, the requirements statements themselves.
  • Conduct informal (peer) review of first draft
  • Conduct formal review of working draft, e.g., with customer and stakeholders
  • Prepare final document (update working draft, tweak graphical representations, identify targets and limits for the highest priority success criteria, make subjective pronouncements about the usefulness of the word processing application)
  • Obtain document sign-off from customer, stakeholders and designated approvers

Now you estimate the number of hours to complete these high level activities, or we may take even more care and create a work breakdown structure so that we can assign hours at the sub-activity level. For example, we may know that there are five primary use cases, the first two will take about eight hours each to draft, review, and stabilize, one will take only four hours, and the other two will take only two hours each because essentially they are the “exception handling” cases for the first two big use cases. For the sake of simplicity, we’ll keep our example to mostly one level. When we assign hours to our tasks, our table looks like this:

Requirements Document Activity Estimated Hours
1 Interview stakeholders and SMEs 24
2 Graphical representations
2a Context setting diagram 4
2b As is and to be cases 4
3 Prepare high-level Use Cases 24
4 Prepare 1st draft of document 24
5 Conduct peer review of 1st draft 4
6 Conduct formal review of working draft 4
7 Prepare final document 8
8 Obtain document sign-off 8
Total hours 104
Total days (8 hours in a day) 13
Total weeks (5 days in a week) 2.6

No doubt for your own particular situations, you would add some additional tasks. At this point our manager thinks we’ve done a great job. And we have done a great job. For example, when we reviewed the list of stakeholders with our customer, we found out that one person on the list had transferred to another group, and didn’t need to be on the interview list. We also found out that a stakeholder would be on holiday during the month that we were hoping to get the document approved, and now we know who to work with in that person’s stead. And, we were able to keep the number of use cases from exploding. So we’ve calculated the hours, and under the best circumstances, we could accomplish the completion of requirements document in the three weeks that we’ve been given.

Ah, but we BAs know the dark truth about this lovely plan. We know that even if our manager cleared everything off our plate, the plan still has cracks in it. There are at least two types of cracks.

First, there are potential delays. From a project management perspective these are risks. Unfortunately we do not itemize them because no one wants to acknowledge that the risks are real. These “risks of delay” are in fact activities that are out of the control of the BA. Here are some examples of uninvited, unloved tasks that are never welcome on a requirements work plan.

  • Review business case (hope like heck that you don’t have to rewrite it because stakeholders aren’t identified, and the validation criteria for the benefits are missing; causing a delay to obtain this information)
  • Meeting(s) to resolve conflicting customer stakeholder requirements; causing delay(s)
  • Meeting(s) to resolve IT stakeholder issues; causing delays
  • Validating that third party vendor’s commercial off-the-shelf solution can support the newly updated projected capacity needs; causing a delay
  • Meeting(s) to resolve the perception that the most recent changes to the requirements in this document now put the project in conflict with another project; causing a delay

This is just the tip of the iceberg. If you have a friendly project manager who is an expert on predicting and representing project delays, now is the time to ask for input.

You may have guessed that the second factor is the presumed degree of BA control over the known activities. The BA role is a hub role, that is, we coordinate as well as analyze information. Under ideal circumstances, the information we collect is complete, accurate, and agreed to by all parties – all we have to do is wave our wand of analysis, et voilà, we have requirements. The reality is the information is evolving (partially complete), somewhat accurate, and only partially agreed to by some of the parties. Our magic wand sometimes seems more like a wire whisk; we have to keep stirring the information to get an acceptable mix.

The previous table only showed an estimate of hours to complete the task. What if we took into account the degree of control a BA has over the task? We can do that by factoring in an assessment of the BA’s control, and associating a time multiple to that assessment. If the BA has full control, then the multiplier is 1; if the BA has only some control, the multiplier is 2. For our worst case, the time multiplier is set at 4. The table below shows an example where the time it takes to complete the requirements document doubles if we acknowledge that some tasks are out of the BA’s realm of control.

Let’s walk through item 1. Interview stakeholders and SMEs. We estimate that we can talk to the three stakeholders and five SMEs in two small-group interviews, write up our findings, and do some follow up, and be done in 24 elapsed hours. In the best case, we would have nearly full control of this activity. But we know that these individuals’ calendars are already fairly full, so we expect to only have some control. In this situation we might multiply the 24 hours by 150% which gives us a best case of 36 hours, and multiply the same 24 hours by 200% which gives us 48 hours for our expected case.

Walk through the remaining line items, calculating best and expected cases. You’ll notice that the only activity that the BA is in full control over in the best case is preparing the first draft. If you don’t know all the intricacies of Word, you may want to give yourself some slack in the schedule to deal with Word’s unhelpful numbering and tendency to size the columns of a table such that the edge of the column is off the visible page.

Range of BA Control on Requirements Documentation Tasks

Scale 1 2 3 4 5
Assessment No control Some control Full control
Time Multiplier 400% 300% 200% 150% 100%

Requirements Document Activity Initial Estimated Hours Degree of BA Control Refined Estimate
Best Case Expected Case Best Case Expected Case
1 Interview stakeholders and SMEs 24 4 3 36 48
2a Context setting diagram 4 4 3 6 8
2b “As is” and “to be” diagrams 4 4 3 6 8
3 Prepare high-level Use Cases 24 4 3 36 48
4 Prepare 1st draft of document 24 5 4 24 36
5 Conduct peer review of 1st draft 4 4 3 6 8
6 Conduct formal review of working draft 4 4 2 6 12
7 Prepare final document 8 5 4 8 12
8 Obtain document sign-off 8 4 2 12 24
Total hours 104 140 204
Total days (8 hours in a day) 13 17.5 25.5
Total weeks (5 days in a week) 2.6 3.5 5.1

Our original requirements work plan predicts that we can complete our requirements document in 2.6 weeks if this document is the only project on our plate. If we consider the typical delays, and account for them by factoring in the degree of control we anticipate, we come up with a more realistic 5.1 weeks. Tune this chart to reflect your situation, your activities will be different, your estimates will vary, the time multiplier is just a variable you can tune. You may want to add an additional column to show the number of people involved in a task. Be sure to provide both best case and expected case scenarios in your work plan to make the risks obvious to your manager and the rest of the team.

The requirements work plan is still a best practice; the additions I have suggested give us a dispassionate way of bringing to light the normal scheduling delays that are a challenge to every requirements document. Be gentle the first time you try using this model, it might give your manager a heart attack. Or, it might give you the opportunity to give your manager some insight into your concerns about the target date you are being asked to meet. There’s no guarantee that even with this much disclosure your manager will change the target date. There is a chance that your manager may work behind the scenes to prepare people to be responsive and avoid the delays.

And wouldn’t that be great!

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

B.A. Survival Guide. Part 3

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on B.A. Survival Guide. Part 3

This month we consider what to do (in some cases) when appropriately selected requirements practices and tools are misused.

Remember, we are assuming that the practices and tools are a good fit for the project, and that they are misunderstood or misused.  Here we go, starting with a BA productivity killer with more impact than many folks realize.

Project Document Deliverable Templates. These are required (and even useful checklists) on larger projects.

Problem:  Even though the template defines a deliverable, management insists on documenting requirements in the templates as they are being discovered and analyzed.  Because templates are “format heavy”, this slows the analysis. Requirements that may not survive analysis are documented along with others that may, and the need to “keep the template pretty” adds significant overhead to all the changes that result.  The overhead is increased even more if some aspect of analyzing or organizing the requirements (outlines, spreadsheets, speculative use case drafts, and attempts to reconcile conflicting or similar requirements) doesn’t “fit the template”.  This is often the primary cause of participant reluctance to allow requirements changes when they are still cost effective for the project because they don’t feel cost effective to the worker who has to do them, and it becomes difficult or impossible to focus on important issues, instead of losing time to “prettification”.

Solution:  Most analysis, especially early in the exploration, is best done with lists, outlines, spreadsheets and other text based lightly formatted tools.  Even use case models are best started as lists, and drawn after the list has been given some thought  As a BA, you must be prepared to produce analysis working documents as well as “formal deliverables”.  Do your best to “finalize” your analysis of the requirements in the format best suited to that process before fitting them to the deliverable.  If management insists, copy and paste your working “requirements” into the appropriate section of the template at the end of each day, and ask for tech writer help in formatting (not changing) them.  Remember – BAs are supposed to be good writers, and good writers are usually re-writers – just do it! 

Use Case Models. These are highly recommended and incredibly useful. What could go wrong?

Problem:  High business value use cases (sometimes called primary – example: I can use an ATM, and when I’m done I have cash in hand) are NOT distinguished from administrative, supporting, or lower business value use cases (sometimes called secondary – example:  I can change my address online, and when I’m done my address is changed). 

This leads to a tendency by the team to over-focus on completing all use cases (or worse, the simpler use cases, which seem easier to complete), at the expense of REALLY working the high value cases until they are completely understood by all stakeholders.  At some point the highest value cases ARE understood (hopefully not months after project delivery), and typically require extensive rework of the “overworked” supporting cast of other requirements.   

Solution:  Do remember that the FIRST use cases in any use case model should be high value use cases, and keep this priority operating at all times.  The high value needs will inevitably drive changes to the lower level details; trust this process and let it work. 

Question:  As an exercise, which of the following business outcomes (potential use case outcomes) could be high value, primary requirements drivers?

A) Customer receives on line order confirmation.
B) Customer sets up account profile.
C) Sales Manager gets sales trend report.
D) Salesperson records monthly sales figures.
E) Customer gives credit card for payment.
F) Customer receives timely refund.

Wait now, don’t peek:……………………………..

  • .
  •  
  • .
  •  

Answer:  A, C, F

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!

© 2009 Marcos Ferrer

Re-Focusing and Re-Energizing Teams

Written by Cynthia Low on . Posted in Articles. 1 Comment on Re-Focusing and Re-Energizing Teams

How would you measure your efforts to involve the entire workforce in resolving problems that inhibit productivity and their ability to succeed? Although there are exceptions to every rule, it is a relatively safe hypothesis that most people want some control over how they perform their jobs each day. A key factor in the success of teams assembled to analyze problems, define requirements and offer solutions is how management responds to those suggestions. If those suggestions are accepted and acted upon, this is often the catalyst for motivating the team to reach for, and achieve, higher levels of quality.

In my experience, teams that are most successful and have the longest life span are those with the fewest layers of “leaders.” Each leader added into the mix represents opportunity to compromise the effectiveness of communication within the organization. On high performing teams, leadership is a shared role. All members are developed to take a leadership role as required. This structure increases the feeling of responsibility for all members.

Reviving excitement in a team is a considerable challenge that can be accomplished if the team can be convinced their efforts are important and will be rewarded. The first step is to understand the causes of the team’s loss of focus. Successful teams often “cool-off” or lose interest more frequently than those who are struggling. The reason for the loss of focus is often boredom. Teams need a reason to remain excited and motivated. Each team is different and will be excited and motivated by different things. Your challenge is to understand what will excite your teams and motivate them to see the value and pay-off for the projects you’re advocating.

Many organizations complain about not having enough time to get their products out, and their inability to meet delivery schedules. In this case, the paramount question becomes: How can the performance of the teams be improved? First, it becomes critical to understand why there is a persistent problem in order to move forward with attempts to refocus the teams. Is the pressure to meet schedules due to insufficient staff to handle the work, a need for better processes, or people not adhering to the processes?

If the perception is that team meetings will only take away time required to complete the work, it is going to be very difficult, if not impossible, to refocus the teams. This is a prime opportunity for management to evaluate the current situation, and solicit the help of the teams to reach viable solutions. If there are not enough people to complete the work, it is going to be difficult to address the problem through the efforts of the teams. However, if the problems can be addressed through process improvements, this is an excellent opportunity to return excitement and motivation to your teams by asking them to improve the processes. I have always found it necessary to know the members of a team as individuals in order to achieve optimum results. Coaching the managers closest to the teams to attempt to understand what motivates each person, and rewarding the person accordingly, will help keep the teams focused. It is also important to demonstrate that their outputs are important. This means that meetings must be treated as work. They must be scheduled the same as other tasks, with attendance manadatory.

Dr. W. Pearl Maxwell is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since 1989, Pearl has developed a successful career as an organizational development practitioner, professional trainer and keynote speaker. Pearl has extensive experience working with process improvement and reengineering initiatives helping clients, such as SCC, Sprint, Rehab Care, Symphony Health Services, to create functional business models for enhanced organizational productivity.

Change Can Be a Good Thing

Written by Cynthia Low on . Posted in Articles.

Transitioning from ITIL V2 to V3

Not to long ago, the ITIL community was collectively starting to breathe again after the long wait for the publication of ITIL Version 3. The word before publication had been that V3 was an incremental update to V2, so we were told not to worry too much.

But what an “increment” that turned out to be! While we knew that V3 would be based on a service lifecycle that was a distinct (but welcome) change from ITIL V2, what we didn’t know was the extent of new material in V3. The old tried and true material was still there (appropriately updated), but two completely new aspects were included in V3, namely Service Strategy and Continual Service Improvement.

To back up for a moment, the IT Infrastructure Library, or ITIL, is a best practice framework aimed originally at IT Operations. The emphasis was on ensuring IT services would run as advertised, and any interruptions to service would be quickly resolved, permanent solutions to problems would be found, etc. Version 1 was written at the end of the 1980s, and a consolidation of the numerous books in Version 1 was done around 2000 and became Version 2. There are two main books in Version 2 (Service Support and Service Delivery) and five ancillary books, which most people are unaware of and even less have read. Both versions are derived from real-world experience and have a great deal of wisdom in them.

ITIL Version 2 gained real traction from about 2001 onwards, and now is a de facto standard.

Many people felt there wasn’t much “broken” in Version 2, so while an update to ITIL was welcome, we were not expecting a wholesale change. Consequently, there was a lot of whining about the necessity of the new material in Version 3.

So what has V3 really given us? After living with the five volumes of ITIL Version 3 for the last year or so, I can tell you it has delivered a lot! While we may not have thought ITIL V2 was ‘broken’, I now believe it was. Probably the best example of how ITIL V2 was “broken” concerns the definition of a service.

ITIL implementations based upon V2 usually stalled after implementing the processes in the Service Support book. The Service Delivery book is really about Service Level Agreements and what you need to do to support them.

A huge hole exists in V2, because it never really defines what a service is in the first place. To fill this gap, customers would often have an exercise to write their own definition, which always ended up being convoluted and incomplete. Consequently, efforts to build processes based upon a poor definition ran into problems, and the processes were ineffective.

The Service Strategy volume of ITIL V3 gives a very good definition of a service. While it looks esoteric at first glance, the definition stands up to scrutiny and provides the basis for all the work that follows on (such as the definition of Service Level Agreements). Additionally, the Service Strategy volume addresses the question of which services should be offered. This is where true business alignment (an often used, but poorly understood, expression) begins!

The Continual Service Improvement volume adds an essential element to ITIL in that it shows how to sustain the effort to implement ITIL. In fact, ITIL is more of a journey than a destination, and effort needs to be expended on a continual basis, just like the old-time, quality programs have always told us. While I believe there will be more added to CSI in the future, the current volume provides a starting point for continual improvement efforts.

ITIL Version 2 had three levels of certification, namely Foundation, Practitioner, and Service Manager. For Version 3, the certification scheme is more complicated, but can be summarized as four levels – Foundation, Intermediate, Expert, and Master. So far, V3 Foundation and V2-to-V3 Foundation bridging classes are available, and additionally, a V2-to-V3 Service Manager bridging class is in the market place (the last course has a very limited audience).

The Foundation classes are very popular. They are essentially there to provide an overview of ITIL Version 3, and do a fine job of providing that.

There are two distinct types of courses at the intermediate level – the Capability courses and the Lifecycle courses. Capability courses are aimed at people who are implementing or running the ITIL processes, and they are the replacement for the V2 Practitioner courses. There are four Capability courses each covering several related ITIL processes. Lifecycle courses are aimed more at managing the processes and will not delve into implementation issues as much as the Capability courses. There are five Lifecycle courses, each one covering one of the five volumes of ITIL Version 3 (Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement).

If you are implementing ITIL processes, or if you have already implemented them and want to continually improve them (you should!), then one of these courses is for you.

In addition to the knowledge gained on each course, they set you on a path to get the ITIL Expert and Master designations.

In summary, ITIL Version 3 has added a great deal to our industry and set us on a path to a much fuller integration of IT into the business. ITIL Version 2, when it was published, was a guidepost we followed until we caught up with its advice. ITIL Version 3 continues that tradition with many new ideas that we at first will struggle to implement, but which we need to do for IT to be valuable to the business.

Geoff Senson is an instructor for Global Knowledge with a specialty in all levels of training for ITIL V2 and V3, especially the intermediate and advanced courses. He has over 30 years experience of IT in a variety of environments, including extensive work in large enterprises. Global Knowledge is a worldwide leader in IT and business training. For more information, visit www.globalknowledge.com

ITIL educator for all levels of V2 and V3; implementation experience of ITIL in many high performance environments; over 30 years experience of IT in a variety of environments, including extensive work in large enterprises

Geoff Senson’s Specialties:
All levels of training for ITIL V2 and V3, especially the intermediate and advanced courses. Cobit training.

About the Author
Tom Grzesiak, PMP, is an instructor for Global Knowledge and is the president of Supple Wisdom LLC. Tom has over 20 years of project management and consulting experience with IBM, PricewaterhouseCoopers, and dozens of clients. He has trained thousand of project managers and consultants. Global Knowledge is a worldwide leader in IT and business training. More than 700 courses span foundational and specialized training and certifications. For more information, visit www.globalknowledge.com

Getting Your Self-Assessment Message to the People at the Top

Written by Cynthia Low on . Posted in Articles.

Communicating upward in any organization can be difficult and stressful for associates who are passionate about their message. This scenario is even more difficult when the associate is trying to communicate his or her own value in conjunction with a growth or financial development plan.

There must be several baseline items considered prior to formulating any communication:

  • The employee should be aware of his/her standing as it relates to “true” performance. It is imperative to be honest with yourself about how the work you do is being received and aligned with both personal and corporate objectives. Many times a gap between performance and objectives due to varying agendas creates a breakdown between employee and employer.
  • The employee should elicit unscheduled feedback during the review cycle to ensure that his/her performance is staying the course. This also allows for a re-alignment of behavior and objectives as the corporate needs and/or culture may shift.
  • The employee should perform a goal/value analysis of his/her standing within the organization. This is accomplished by aligning your beliefs, goals and values with the organization you work for. It is imperative that the employee be sure they are not forcing the continued relationship. This is one of the most important factors in the effort to ensure job satisfaction and ultimately one of the most overlooked. Getting yourself into a rut is the most common mistake when evaluating self-worth and ultimate career goals. Change is hard, but sometimes it must be made.
  • The employee should have a plan that illustrates their objectives, and, most importantly, structure this in a collaborative way to ensure it is not received as an “agenda.”

Once the employee completes the development of a baseline communication plan as noted above, the following items should be crafted into the delivery format:

  • The employee would be well served to draft a brief for the communication. This is not suggesting an agenda, but something less formal to incorporate a value statement, self-assessment, recent accomplishments, past performance analysis and desired path forward. The brief can be used as a guide during the presentation and may or may not be handed out. Most importantly this exercise helps the employee to formulate and format an organized presentation.
  • The employee should have considered a coaching/mentoring plan to support their desired development and present it in a low key yet confident way. This action will expose his/her willingness to learn and dedication to continued development.

The employee should consider what financial expectations are associated with the next step in their career and know how these expectations align with the organization’s structure. In small organizations requests for profit sharing and limited vesting are not uncommon but need to be considered carefully as the “owners” are far more protective than a “supervisor.” In these cases, present tenure, contribution and continued value-add as the long-term benefit. It would also be helpful to illustrate historical growth and commitment to support a more intimate relationship with the organization.

When the items above are complete all of the pieces are now ready to deliver a well-planned communication to your boss. Here are some delivery notes that will be helpful when making the presentation:

  • Always open with a quiet yet confident statement about why you have called the session. It is important that your confidence be very visible but not taken as over aggressive.
  • When aligning your plan with that of the organization, try to leverage real life examples of how the efforts you have contributed showed value above expectation. Additionally, you want to look forward to how this path will create continued value and growth.
  • Never brush against the essence of “entitlement.” Remember that the organization does not “owe” you anything. This is very important especially when requesting further vesting and/or initial vesting in small organizations.
  • Take the time to understand your boss and his/her expectations, goals and relationship with you. It is always helpful to prepare by role-playing with a “non” co-worker to establish a smooth delivery.
  • Never share your plan or thoughts with anyone else in the organization.
  • Plan a neutral location for the meeting, off site always works best to level the field and avoid distractions.
  • Don’t represent a position of “negotiation.” You are not there to win/lose, you are there to identify value add points for your own position and the organization. The best-case scenario will play out naturally if you guide the process with integrity.

Once this process is complete, repeat the goal/value analysis. Unfortunately, one of the worst positions you can be in is one of weakness once the results are rendered. In other words, be willing to make changes against to your personal career plans if you are not comfortable with the results of the effort.

Time is your most valuable commodity.

Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since founding AMS nearly two decades ago Phil has lead the organization to becoming an internationally recognized provider of Consulting, Training and Assessment services. AMS’s client base is comprised of Fortune 100/500 companies, medium-sized businesses and Government agencies that Phil has personally assisted in the creation of organizational and performance based solutions. Phil has designed business methodologies, processes and personnel performance plans for organizations such as, AT&T, Fidelity, The Hartford and many more. Phil maintains an active role providing executive coaching and account solution development for the AMS family of clients. As an entrepreneur Phil has founded AMS Aviation and PTV Equity both wholly owned subsidiaries of AMS.