Tag: Planning

Requirements Definition Phase – Are We Done Yet?

Written by Cheryl Hill on March 30, 2010. Posted in Articles.

People often ask me “how do we know when we are done with the requirements phase?” My opinion? You are never completely done with requirements but criteria do exist by which you can assess the completeness of your requirements and gauge your readiness to proceed with design.

Criterion 1: Let the Scope be Your Guide

Okay, my assumption is that your project has a defined Scope. You know, that’s the document you produce at the outset of the project that serves as the foundation for writing requirements. As a refresher, the components of Scope are:

Need: The problem you are trying to solve or the opportunity you want to exploit
Goals: Things to accomplish to meet the need
Objectives: Criteria for success
Interfaces: External entities (people, processes and systems) that will send inputs to, or receive outputs from, your product
Drivers and Constraints: For example, regulations, standards, existing systems used with your product, higher level requirements, schedules, budgets, stakeholder expectations
Operational concepts: These are stories or scenarios that describe a day-in-the-life of your product for different lifecycle phases (e.g., operations, transportation, installation, maintenance, storage, manufacturing, disposal) from different stakeholder viewpoints

Every requirement you write should be in response to one or more components of the project’s scope. If the requirement does not help you meet the scope, you probably don’t need it. This said, look at the components of your scope and ask yourself, have you defined the requirements necessary to meet the need, goals, objectives, interfaces, drivers and constraints? Have you documented all the requirements that you derived from the operational concepts? If you answered yes to all these questions, you may be ready to baseline your requirements and proceed to Design, but just to make sure, I recommend that you apply additional criteria.

Criterion 2: Look at Your Models

If you developed models using business process, object-oriented, or structured analysis techniques, then you have on-hand a great way to verify that you have a complete set of requirements. When I speak of models, I am referring to Activity Diagrams, Swim Lane Diagrams, Flowcharts, DFDs, ERDs and the like. I am a staunch advocate of modeling. Developing models is a great way to engage the stakeholder and get them to communicate their requirements in a non-intimidating and comprehensive way. By non-intimidating I mean- how scary is it to draw a picture to graphically present what is done today or that which is wanted in the future? Comprehensive? With a picture, you can easily validate steps and decision points and identify errors and omissions.

When I assess the completeness of my requirements, I prefer to work from both my current state and future state diagrams. By analyzing both states, I increase my confidence level that I have the requirements to sustain existing function, performance, and compliance needs as well as define the requirements essential to achieve the defined Vision and scope.

Criterion 3: Look at Your Template

Did you use a standard outline or template for your requirements? Many organizations have developed standard templates for different type of projects…hardware projects, software projects, maintenance, upgrades, etc. A well-constructed template lists the different types of requirements that are typical for the various types of projects/products of an organization. So, if you use a template, make sure that all relevant requirements have been gathered and documented. Excuse me for stating the obvious but a big hole in your template is a pretty good indicator that you are missing some requirements.

Criterion 4: Conduct a Requirement Review

I know…the dreaded review…with your gasp stakeholders!!! But you know, a requirement review does not have to be a horrifying experience and it really is the best way to ensure that you have a complete set of requirements.

Follow these simple rules and the pain you associate with the requirement review will be minimized:

Make sure the requirements document is ready for review. Correct all typos, grammar problems, punctuation errors. Also, make sure that all requirements are written according to the rules for writing good requirements. We want people to focus on the content, not stupid little errors!!
Include all project stakeholders in the review. I also recommend that you invite knowledgeable people from outside the project to gain perspective of those not so intimately involved in developing the product requirements. These outside “experts” need to be technically competent and have worked on similar development efforts.
Make sure that all reviewers understand the Scope of the project. If people are reviewing the requirements with no concept of the Vision, of the scope, you are wasting everyone’s time.
Conduct a Review Kickoff Meeting prior to distribution of the requirements document. In this meeting, presentation topics include:
- Purpose of the review
- Expectations of the reviewers
- Rules for the conduct of the review
  - Criteria for the review
  - Standards
  - Templates
  - Review comments
  - Feedback
- The project scope
- Other information you feel the stakeholders need to successfully perform their review tasks

The intent of the requirement review is many-fold:

Identify and correct errors and omissions
Confirm the correctness and completeness of the requirements
Obtain buy-in and agreement from all stakeholders
Set expectations
Get sign-off

Criterion 5: Cost/Benefit

Okay, I admit, regardless of what you do to validate you are done with the requirements phase, you still have those “hand-wringers” that refuse to sign-off for fear you are missing some really important requirements. You think you have all the requirements, the majority of the stakeholders think that you have all the requirements, but you, and probably everybody else, secretly want a single one indicator that screams that you have all the requirements and are ready to baseline and start designing. Sorry, no such indicator exists. If you are in a quandary about whether you are done with requirements or not ask yourself this question…

What will cost less – potential downstream changes because I forgot some requirements or the time, schedule and resource investment required to make sure that I have defined every possible requirement?

A word of caution; there are people who are on the other side of the spectrum from the hand-wringers…I call these people the Schedule Mongers. Schedule Mongers are those who insist on starting the next phase of a project irrespective of the status of the current phase because “see it’s on the schedule and if it’s on the schedule, we have to start!!” When assessing the readiness to move to Design, the Schedule Monger does not necessarily care if the requirements are done and is oblivious to, or in denial of, the fact that starting without a good set of requirements will definitely cause a slip to the product delivery, add costs, and probably result in unsatisfied customers. So beware the Schedule Monger and know that the question you ask about the risk (cost) of proceeding, or not, is just as applicable when dealing with the Schedule Monger as it is with the hand-wringer.

Conclusion: Are We Done Yet?

Ludwig Wittgenstein stated “The riddle does not exist. If the question can be put at all, then it can also be answered.”

Hmmm…I suspect that Ludwig never had to deal with requirements!!!

You will never be done with requirements because things change – businesses change, technology changes, competition changes, people change. And, it is because of this inevitable change I feel that the question “When do we know we are done?” cannot be answered with 100% confidence.

However, if you assess requirement completeness within the confines of:

your defined scope,
the developed models
your organization’s comprehensive requirements document templates; and
you enlist your stakeholders’ participation to confirm a comprehensive and correct set of requirements; and
you evaluate the potential costs of future changes with that required to foresee every requirement,

then you can answer that question we often hear during the requirements phase – are we done yet?

The answer??

No we are not done yet but we are done enough to proceed to design.

Don’t forget to leave your comments below

Cheryl Hill, PMP is Chief Operating Officer and senior instructor for Compliance Automation, Inc., a leading provider of requirements training and other services to help companies, government organizations, and individuals produce defect-free requirements in the most efficient and effective manner possible. Cheryl, along with all of CAI’s trainers/consultants, brings to the classroom 20+ years of real experience in project management, requirements and other areas of system engineering and business analysis. Since 1990, over 25,000 of our customers have looked to CAI for pragmatic approaches to analyzing and managing scope and requirements. At CAI, we deliver training to our customers that is necessary and of value to the individual and the organization, long after the training is complete. For more information, call us at 830-249-0308 or visit us at www.complianceautomation.com.

Free, Easy and Powerful Tool – the CBAP 007 Scope-O-Matic!

Written by Marcos Ferrer on February 16, 2010. Posted in Articles.

Just in case any of my readers think I (yes, I am CBAP 007) am only good for political analysis, I offer a simple BA “tech” goodie (our tech is different from their tech – this one works with paper and pencil, in a pinch!).

If you have ever been in a project where scope keeps wandering, even after endless discussions, just use the 007 Scope-O-Matic to sort it out in your mind. Once this is done, it will be easier to sort it out with the stakeholders.

Don’t write me telling me that this is the project manager’s responsibility – the project manager doesn’t face confused stakeholders day after day. Sometimes the PM acts like another stakeholder, announcing scope as if no one else could understand or discuss it. Often it is not in fact understandable, usually because it is oversimplified, and discussion is not welcome.

The secret is in not oversimplifying the scope (“To do requirements for a new order entry system” is not clear at all) and putting good boundaries on the problem. It is not enough to say what is in scope – often what is in scope “implies” other issues, not made explicit, yet leading to multiple confusing meetings.

Now, with Scope-O-Matic, you can identify more detail in your scope, and you can identify what is out of scope, and what is ambiguous in scope, as well as what is in scope.

If you have never tried this, you are in for a treat. Even if those around you never do sort out the “true” scope, you will have a lens into the confusion, one that will help you keep your head, while all around are losing theirs.

Have fun, let me know what happens. Even five minutes with this tool will teach you things that you know but hadn’t articulated – it is a great “gap” analyzer – do it for your project today!

Keep the discussion coming, here is your free tool!

IN and OUT of SCOPE, with “Possible Ambiguities”

IN SCOPE	???	OUT of SCOPE

Build a Prototype system	Creation of a Prototyping Demo Environment?	Creating an application environment.


Creation of a Prototype covering Order Taking, Picking and Shipping	Electronic orders or just phone orders? Faxes?	None of the marketing that leads to a customer making an order


Elicitation of user interface and functional requirements using prototype	Capture or dispose of business rules discovered during elicitation?	Elicitation of software, security, reliability or any other non-functional requirements

Documentation of functional Requirements and user access privileges	Are user access privileges a part of security requirements?	User or programming guides, response time requirements, system uptime, system scalability, etc.
Screen shots (in documentation)	The screens have over 15,762 permutations, if you count menu views – how many screen shots?	Functioning code of any kind
Process (functional) requirements (use case model & text)	Level of detail?	Traditional FRD non-documentation
Assumptions made by requirements team	How to bridge critical “unspeakable” assumptions?	Assumptions that are “unspeakable” yet critical


THE REST	IS UP	TO YOU

Have fun!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

The Business Analyst’s Guide to Dealing with Difficult Sponsors

Written by Dana Brownlee on January 5, 2010. Posted in Articles.

Part of the challenge that the business analyst faces is the reality of having to serve so many different stakeholders and sometimes being pulled in very different directions. We’re often taught that our sponsor is the person who is the champion of the effort. Indeed, they are often the one we’re to seek out for support and issue resolution throughout the project. But what do you do when your sponsor is the problem??? As I travel the country and beyond to speak to business analysts, project managers, and team leaders about how to best manage problem attendees in their meetings or deal with difficult team members, I am astounded by how often someone raises their hand to ask, “But what do you do if your sponsor is the problem?” I have to admit that that does pose an interesting dilemma, but it’s not one void of strategies you can use to address this not too uncommon problem. Let’s explore a few different varieties of the difficult sponsor and see how they can be managed for optimum success.

Sponsor Type 1.

I hope you don’t mind me intimidating everyone with my overbearing nature at your team meetings…I’m just trying to help you speed things along J.

Sometimes the problem is getting the sponsor to show up for meetings as requested. On the other hand, sometimes we’re sorry they did show because they become our problem participants and that can be difficult to manage. Try these meeting facilitation techniques:

Meet with the sponsor prior to the meeting and specifically discuss what you need from them in the session. Possibly write out talking points for them – many will appreciate it if it’s offered in the spirit of helping take one more thing off their plate (not telling them specifically what to say). Ask them to withhold their opinion until others have weighed in to avoid tainting others’ input.
If you sense others may be intimidated by the sponsor’s opinion, suggest the group do a round robin and start at the opposite end of the table to the sponsor (so that their opinion comes near the end).
Stand up! Whenever you stand when everyone else is seated, you immediately regain control of the group (temporarily). Thank the sponsor for their input (even note it visibly) and redirect the conversation as needed.
Repeat their point and write it down – this may sound counterintuitive, but oftentimes a sponsor will get on their soap box (and not get off it!) because they don’t feel heard. When you repeat the point back to them and then write it down for all to see (on a flip chart or whiteboard), it reassures them that they have indeed been heard and immediately communicates an appreciation for their point.
Ask for solutions – sometimes meeting participants (even sponsors) get caught in a cycle of whining and venting about problems. After agreeing with the issue (if appropriate or not, offering an opinion if you don’t agree), simply ask the sponsor to suggest a solution. Insist that the issue being raised is important enough to warrant devoting some energy to focusing on a solution.

Sponsor Type 2.

I’m not exactly clear on what I’m looking for, but I’ll be sure to hold you responsible when I don’t get it…

Clarify the effort early and often. Identify in scope items and out of scope items (out of scope is critical), tangible deliverables, timing expectations, budget restrictions, roles and responsibilities, known risks, and key stakeholders.
Identify their soap box issue early and emphasize WIIFT (What’s in it for them). If they don’t understand exactly what they want, ask them to explain their motivation/driving factor. Often, execs have a soap box issue, predetermined bias, or hypothesis they want validated. Try to find out what this is as soon as possible.
Ask the sponsor to prioritize cost, time, and scope (good, fast, and cheap). Which is most important (relative to the others)? Hint: The answer is not all three. Think McDonald’s – their focus is very intentionally fast and cheap. Be clear which constraints are really driving the project.
Explicitly ask how they will define success. Always ask the sponsor to finish this sentence…I will consider this project a success if…

Sponsor Type 3.

Would you please boil the ocean? (and solve world peace too while you’re at it J)

Try to identify the specific mandatory requirements (and separate the “wants” from the “needs”). Sometimes they will ask for a Porsche when a skateboard will do. Also, there may simply be a knowledge gap and they don’t realize that there is a quicker, easier way to get them what they really want.
Document your risk analysis. Although we know that virtually all projects encounter problems, we usually spend little to no time analyzing risk before the effort starts. Don’t make that mistake! Assemble a few key stakeholders, brainstorm a list of potential risks, then estimate the likelihood and impact of each event. For each risk event, multiply the likelihood by the anticipated impact to quantify the severity. Add the severity of all risk events to determine an estimate of risk for the project. Here’s an example:

Risk Event Probability of Occurrence Anticipated Impact Severity

Supplier goes out of business 20% $1M $200K

Team loses key resource 75% $100K $75K

Inclement weather occurs 50% $200K $100K

Technology fails 20% $500K $100K

Total Estimated Risk $475K

Check with the sponsor to ensure he or she is comfortable with that level of risk (e.g. $475K in the example above). Also, ask the sponsor to help you come up with a back-up plan proactively (e.g. Jim, I know that if we lose our lead system architect, it will severely impact our timeline. In an effort to be as proactive as possible, I’d like to find out from you what we can do in the unlikely event thatt does happen?) Even if they insist that you proceed, your having documented these risks will be very valuable to you and the team. If you are proceeding, work with the team to prioritize risks and identify mitigation strategies and/or back-up plans for the most severe risks.

Remember the triple constraint – when they change one element, it impacts the others. If there is a reduction in time, emphasize the impact on cost and scope. (e.g. Jim, I understand that you now need to roll out the new release a month earlier than planned and we can do that, but there will be an impact on cost and scope. I can either reduce the scope and hold off on some of the features until the next release or spend about $50K more to expedite things. What is your preference?)
Push back if it’s not realistic…(e.g. Jim, I would be irresponsible if I didn’t tell you that I don’t think this can be accomplished with the level of quality we would expect. I know you would prefer that I be very honest now (before any time and money have been invested) rather than hear a laundry list of apologies after an unsuccessful project. I’d really like to be positioned for success, and I honestly have real concerns here).

Sponsors are supposed to be our protectors and oftentimes they are. Unfortunately, the difficult sponsor can make an already challenging project excruciating! Admittedly, dealing with a sponsor is a unique challenge due to the political realities, and there are no easy answers. Sometimes a difficult sponsor does not respond to reason and helps contribute to a very negative experience for the business analyst. More often than not, the business analyst is too intimidated to deal with the situation at all. Don’t make that mistake. Proceed with caution, use tact and diplomacy, be strategic, but do address the issue. The sophisticated business analyst can indeed manage many stakeholders – even the difficult sponsor!

Don’t forget to leave your comments below

Dana Brownlee is President of Professionalism Matters, Inc. which owns and operates www.meetinggenie.com, an online resource for meeting facilitation tips, training, and instructional DVDs. Her latest publications are “Are You Running a Meeting or Drowning in Chaos?” and “5 Secrets to Virtually Cut Your Meeting Time in Half!” She can be reached at [email protected].

Change Management; What Exactly is Buy-In?

Written by Kelly Burroughs on October 27, 2009. Posted in Articles. 1 Comment on Change Management; What Exactly is Buy-In?

When it comes to change management, the term ‘buy-in’ is tossed around the office like a baseball around the diamond in a pre-game warm-up. It is a term used to indicate the need to convince everyone to get on board the change train, as it is destined for great things. But I find this term funny, because it indicates the change has already been decided, the train is leaving and I better get on or…well stay behind. And then we wonder why there is resistance to change.

But what if change was not something that was imposed on people, but was something they themselves came up with?

So many times I have worked on a project where a decision is made at an executive level, and then announced to the business with a fancy PowerPoint slide show, a few bullets about what the benefits will bring, and the overall concluding message of “we are doing this regardless, so you better get on board”. And then we wonder why there is resistance to the change. But the fact is, if you make the decision to change without first asking the people the change will affect most, chances are pretty good there will be a defensive and resistant reaction.

One example that comes to mind is a company that decided to reorganize the entire organization without telling the employees until a company wide meeting was called one morning. Employees shuffled in, took their seats and found staring back at them, a man dressed up in a bear costume and fireman’s helmet, there to put out the ‘fire’ (and make the PowerPoint presentation). Needless to say, the reaction from the employees was not a good one (and going into the many reasons why might just be another article all on its own). In the end the meeting was not a productive one and, in fact, put many employees on the defensive about their job security and their role within the company. Everyone left more confused than when they had arrived, and nobody remembered any of the benefits listed within the PowerPoint presentation (but will probably remember the bear costume for life!).

But what happens if you skip the fancy PowerPoint slide show, and get the non-IT folk to come up with the idea in the first place? Would there still be resistance?

People have a tendency to want to own things – whether it be their house, car, yacht, or the job they perform on a day to day basis. Because to many people a job is a set of daily routines and procedures they have become accustomed to doing on a daily basis; and more than that, have become very good at. To then introduce change into that daily routine without consulting or involving them, is the equivalent of stealing their car from their driveway and trading it in for something new, without asking them. Now some people might be happy with a new car, but many people would resist the new car and want their old one back. Maybe they wouldn’t like the colour because they didn’t pick it, or maybe they didn’t really want the upgrade to a sunroof because they once had a bad experience sticking their heads through one. Maybe they just did not like the fact that the decision to get a new car was not theirs. And there is no difference with change in the workplace. If you just suddenly take something away from somebody and replace it with something that you may think is better, you can almost be guaranteed they will find something wrong with it, and NOT think it better.

So then, how should change be introduced?

How about driving the change from a lower level? With so many change initiatives coming from the top of an organization, you constantly have a top-down channel of communication, which often puts those on the bottom on the defensive. How many times have we heard in reaction to a change: “Why do we need that? What is wrong with the way I do my job now?’ But what if what if those who would be most affected by the change were approached at the start and asked things like:

So what currently holds you up in your job?
Is there anything you do now that is completely manual?
Is there anything in the current process that you think should be changed which might make it easier for you to do your job?
Would you like to be involved in looking at new software for what you do?

Would they then see it as change, or would they maybe see it as something they can own, or do, to improve their jobs?

To me, getting others in the business to see the issues, own the issues and then, because of it, want to be part of the solution is the key to incorporating change into a company. It is surprising how often people are willing to be a part of projects, if they are just given the chance to get in at the start. But to be just told they are on a project, which ultimately affects their job, is often times a setback right from the beginning.

There will always be those who think making the decision and then showing the fancy PowerPoint presentation with the benefits of the solution is the answer to introducing change. But to me, change should never have to be introduced to the business – it should be generated upwards from the business. Getting people to realize the problems themselves, and come up with the solution themselves, will almost always work because people take pride in what they own and want to make their ideas work. Because remember; there is very little difference between ‘change’ and being ‘creative’. The only difference lies in where the direction comes from. You tell somebody to do something and they cringe at ‘change’, but if you get them to come up with the idea themselves they are ‘creative’, and will take pride in being so.

Don’t forget to leave your comments below

Kelly Burroughs is a Business Analyst/Project Manager for Halsall Associates, a professional services engineering company. She has several years experience in implementing larger scale technology changes into businesses, as both a business analyst and a project manager. She can be reached at [email protected].

Is the Business Analyst’s Work Ever Done?

Written by Jill Liles on June 9, 2009. Posted in Articles. 1 Comment on Is the Business Analyst’s Work Ever Done?

Solution Assessment and Validation

The business analyst’s work is not finished when the requirements document is signed off. Although other experts are responsible for the project activities, the BA remains involved to ensure that decisions made have no adverse impact on the business stakeholders. As the project moves forward, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the final solution will satisfy the requirements.

After the solution has been built, the BA collaborates with many people on activities such as testing, conversion, cutover, and training. Depending on the roles defined in an organization and the project, the BA may collaborate with the people who are responsible for these activities, or the BA may be the responsible person. In either case, the BA ensures that all of the right things happen.

Monitor Solution Design and Planning

As the technical team derives the solution design, the BA must learn enough about the implications of that design to ensure that it supports the requirements well. For example, the BA might:

Review user classes to ensure that all of the solution functions, uses, and end users have been accounted for.
Review the developers’ functions and feature list for completeness.
Map the documented requirements (both functional and Quality of Service) onto the elements of the system design to ensure complete coverage.

When the technical team defines its phasing plan (which identifies the order in which requirements will be addressed and functionalities designed and built) for incremental development, the BA must ensure that the plan supports the stakeholders’ needs. If the plan calls for features to be delivered in a certain order, the BA should ensure that the planned order and delivery dates would be useful to the business stakeholders. The BA should also ensure that the phasing plan provides opportunities for any needed prototyping or validation during the project.

Tracing the requirements to the design is a good way to ensure complete coverage, and it lays the foundation for maintaining traceability throughout the project. The traceability information must be captured and recorded as the designs are being done, as trying to derive the traceability after the fact is difficult, if not impossible.

Finally, as the solution is being designed and built, the BA may identify business process improvements that are unrelated to the solution but that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Final Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to ensure that those deliverables satisfy the requirements and can be used by the intended end users.

System testing looks at the final system to determine if the requirements have been satisfied. System integration testing refers to testing the final solution to ensure that it can coexist and integrate with existing systems and databases. Many organizations have an independent testing group whose main responsibility is to prepare for and perform these tests. When that is the case, the BA will usually review the test plans and the test results, and at times, the BA may help with the testing. However, in organizations that don’t have testing groups the entire responsibility falls to the BA.
Operations testing involves testing the final solution to ensure that it can be installed and run without an adverse effect on the other existing systems. If the computer operations group takes responsibility for this testing, then the BA will usually review the test plans and the test results. But if this testing is necessary and no one takes responsibility for it, then the entire responsibility for this testing falls to the BA.
Acceptance testing ensures that the business need and user’s needs have been fully satisfied. If the customer takes responsibility for this testing, then the BA will usually review the test plans and the test results. Otherwise, the entire responsibility for this testing falls to the BA.

Assess Other Solution Options

The BA should collaborate with a variety of people on the project as the solution is being put together. In all cases, expect the experts in each area to be making good choices. The BA’s role in the collaboration is merely to serve as the business stakeholders’ advocate and assure that their needs will ultimately be met.

Although the technical team takes the lead in evaluating and deciding on the technologies that could be employed to build the solution, the BA should remain involved. This is because every technical choice has the potential to cause limitations in the final solution that will be noticeable to the users. So, the BA must learn enough about the effects of the team’s technical choices to ensure that they actually do support satisfying the requirements, and ultimately, the business needs.

When the plan involves purchasing or leasing (as opposed to internally developing) a solution, the BA may take the lead in choosing the solution. But even if someone else has primary responsibility for this, the BA will still remain closely involved. The BA ensures that any RFP (request for proposal) or RFQ (request for quote) accurately translates the requirements. The BA should also verify that the proposals received will fully meet the business need. And, when the solution is finally received, the BA ensures that it is adequately tested to be sure that is actually satisfies the requirements.

Support Implementation of the Solution

In some organizations, an operations team takes the lead in implementation, but often the BA is responsible. In either case, the BA must remain involved to ensure that implementation and any necessary conversion meets the needs of the users.

The BA ensures that any necessary installation planning is done, and that the appropriate technical experts review that plan for correctness. This could be as simple as ensuring there is enough disk space for the new software, or as complex as replacing entire computer systems with new ones.

Conversion is almost always an issue. Since the solution is most likely changing some attribute of the business process, there will probably be data conversion; there may also be other kinds of conversions to be done. Planning for these includes identifying the rules for handling the inevitable problems that will be found.

Finally, the plan to the final cutover to the solution must be well thought out. When should it happen? Will there be downtime involved? If so, how much is acceptable? An important, but often overlooked item is the “backout” plan. If the cutover fails, what must be done so the business can resume working with the old system? If there is significant data conversion or other changes, this can be a difficult problem.

Communicate the Solution Impacts

The responsibility of communicating the impact of the final solutions is assigned to different people in different organizations. In any case, the BA must still remain involved. Before the new solution is implemented, the BA should work with the business stakeholders to ensure that they are ready for it by:

Ensuring that everyone who needs to know about the implementation has the information they need, when they need it, before implementation
Setting the expectations of users and other stakeholders about how the change will affect them and the business process
Making sure that any needed training and help is available to the users in a timely manner

After the implementation is complete, the BA collaborates with the appropriate people to report on the implementation. This reporting provides pertinent information to all the parties who need to know that the implementation took place, and if there were problems. A key item is the business impact that the change had. Since the project was undertaken to improve a business process, the actual impact on the business process is of major concern.

Perform Post-Implementation Review and Assessment

The final validation occurs after rollout of the solution is complete. This activity, also known as “Lessons Learned,” is designed to help the organization learn from each project, supporting continuous process improvement.

You need to capture these successes, identify why they happened on this project, and determine what can be done on future projects to make them routine. The parts of this project that worked particularly well represent opportunities for future projects.

By the same token, if there were things on this project that were problematic, they also represent opportunities for improvement. You need to capture these issues, identify why they happened on this project, and determine what can be done on future projects to avoid them.

The Lessons Learned review is one of the most potent mechanisms for organizational learning and continuous improvement, as long as you actually use what you learned in future projects.

In Summary

Solution assessment includes all the activities that the BA collaborates in to ensure that the technical and other decisions being made by the development team result in meeting the needs of the business and users. These activities include design decisions, phasing for incremental development, maintaining the traceability matrix, choosing technologies, procuring solutions, and ensuring usability.

Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge’s Requirements Development and Management course.