Skip to main content

Getting Back to Basics – Fifth Fundamental-Choosing the Best Modeling Technique for Success

Written by Cynthia Low on . Posted in Articles.

In April, I began a series of articles devoted to the basic practices of business analysis. With so much information now available, I felt it was important to go old school and make a case for the core principles of the discipline and why they represent the best path to success. 

Since beginning the series, I’ve talked about understanding business goals, creating a common vocabulary, identifying sources and choosing elicitation techniques.  Now, in this final installment, I’ll be discussing which modeling techniques are most appropriate for a given situation.

Why We Model in the First Place

They claim a picture says a thousand words, but, in business analysis, it’s the opposite. The thousands of words you elicit from your stakeholders make up one picture representing a summation of disparate information. Modeling is essential for drawing a clear, accurate picture of a given project’s true business needs. 

In addition, modeling helps you define your project’s scope and begin prioritizing the mountain of requirements you’ve gathered.  A well-drawn model is a concise model, which will allow you to clear away the erroneous, redundant information that inevitably clouds your view of the path ahead. The types of models you use may very well address the different levels of knowledge and means by which a stakeholder can best articulate his or her vision or needs. For example, if you’re dealing with highly systematic thinkers and are eager to both elicit and validate requirements, you may likely choose to develop a variety of tables and checklists. Or, for more creative, big-picture, visually minded stakeholders, you’ll leverage story boards and use-case diagrams.

Four Classes of Modeling

Those new to business analysis-and, frankly, those not new-often confuse the terms model and diagram. A model represents information at the highest level, and diagrams are the tools that make up a model. Think of a model as a newspaper, and the diagrams as the many sections within.

Speaking generally, we could put all models into four categories.  All four can and should be used to varying degrees for all types and levels of requirements.  However, a trick for distinguishing them and determining when one is more appropriate than the others is to align the classes with five questions: Who? What? When?  Why? How?

1. Structured Models
When the question is What?—as in, What is supposed to happen?–-developing a Structured Model is an effective modeling technique. An example of an applicable process could be: if an expense is approved via an online approval system, that request is then sent to a third-party payroll organization. The diagrams you could use to build your structured model in this case include a glossary of terms-which we discussed in the second article in this series-as well as domain and location diagrams. By using a glossary of terms, you can ensure the clarity of what is being used or what systems are involved.

2. Behavior Models
Behavior Models are the best tool for answering the Who?  Who’s going to maintain a company’s Intranet site?  Who’s going to act as a backup in the event that a technical expert is unavailable?  Who’s going to be responsible for ensuring that monthly attrition changes are made to a company’s payroll system? This modeling technique can also answer a second question: How?  How will a system be updated, manually or automatically?  How will progress be reported up the food chain, by e-mail or directly during conference calls? 

As the name indicates, we’re dealing with human behavior here, and, in the workplace, that usually translates to individual roles and responsibilities.  Therefore, diagrams include behavior categories as well as process maps and use-case maps.  Also, when creating a behavior model, don’t forget your stakeholder categories, which we discussed in detail in the third article in this series.

3. Control Models
Now, on to my three-year-old son’s favorite question: Why?  Control Models tend to focus most successfully on justifying why something needs to be done, or why it is valuable to do something a certain way.  And, quite often, the answers can be found in the business policies and rules that you’ve collected throughout elicitation.  An organization’s individual policies, for better or worse, often determine the course of a project.  For example: When an associate project manager makes a purchase request in excess of $10,000, that request will automatically bypass his or her direct boss and be sent to the head of the division.  Why does this have to be done?  Because, those are the rules, kiddo. 

4. Dynamic Model
Finally, Dynamic Models, although not used as often as the other classes, are all about When? When will reports be generated?  When will the first stage of the project be completed?  When is this article due to BA Times?  Dynamic Models will be made up of your most time-driven diagrams, which may include event tables or detailed timelines.

Best of Luck

And with that, our whirlwind back-to-the-basics tour has come to an end. I wish you luck in your future endeavors, and hope that you remember the value of our discipline’s basic best practices.

If, for some reason, you missed any of the four previous articles, don’t worry.  The film version of the series starring George Clooney will be hitting theaters worldwide this fall!

Glenn R. Brûlé has more than 18 years’ experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.

ITIL v3 and Service Management

Written by Terry Longo on . Posted in Articles.

Back in April I introduced the subject of ITIL and its contribution to an increasingly successful BA/IT relationship.  At that time, most ITIL-based IT organizations were using ITIL v2, with implementations focusing primarily on operational IT efficiency.  The necessity of strong IT/business alignment is emphasized in ITIL v2, but ITIL v2 lacks a compelling framework within which that alignment can be understood and materialized.  This can actually be deduced from the organization of the ITIL v2 books and chapters, with the ITIL processes themselves (Incident Management, Problem Management, Change Management, etc.) as the main topics.

 

 

ITIL v3, introduced in May 2007 (you can find a good starting point for additional ITIL information here), not only subsumes the IITL v2 content but

  1. Reframes it entirely, presenting the material within the business life cycle phases of Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement
  2. Introduces Service Management as a generalization of IT Service Management (with very interesting implications for BAs – to be covered in my next article)

 

Have you looked into ITIL v3?  Do you work with an IT organization that is adopting ITIL v3?  Do you have plans yourself to become ITIL Expert certified, to complement your CBAP certification plans?

When Does The Business Analyst’s Involvement In A Project End?

Written by Cynthia Low on . Posted in Articles. 1 Comment on When Does The Business Analyst’s Involvement In A Project End?

july15_car_200x133.pngWe’ve got another line-up of timely articles examining the field of business analysis and surrounding areas. I feel certain that you’re going to find some interesting and provocative ideas and we look forward to your responses, both positive and negative.

 

  • When is the BA’s Work Finally Finished? Many people think (some BAs and PMs included) that the BA’s work is done when they’ve signed off on the requirements document. Jill Lilles points out that BA’s role in the project is far from over.
  • A Second Look under the Hood of the BA/PM Position Family. Bob Wysocki continues his series about the over-lapping roles of the BA and PM. In this article he takes a deeper look at the relative prominence of the two roles in different phases of their careers.
  • IIBA. Check the IIBA section for the 2008 Annual Report and some comments.
  • This issue’s blogs. Marcos Ferrer revisits the challenge he threw out last month and asks why BA s don’t have the same level of empowerment as many other professionals. Terry Longo talks about the side-by-side roles of the business analyst and the business manager. And I’m heading for a long weekend away from all forms of electronic communication ….I think. I promise not to….

All the best and I hope you’re managing to enjoy the summer without too many interruptions.

Adam R. Kahn
Publisher, Business Analyst Times
[email protected]

A Second Look under the Hood of the BA/PM Position Family

Written by Cynthia Low on . Posted in Articles.

This is the sixth article in the series. In the previous article (A First Look under the Hood of the BA/PM Position Family) I defined the BA/PM position family and the career path sequence. Then I wrote the generic position descriptions of the six-position family. The structure and ordering of the six positions in the BA/PM landscape is now defined at the generic level. Each of the 36 cells in the BA/PM landscape has now been generically defined with respect to the BA/PM position family.

Depending on the extent to which project management and business
analysis exists in your organization, there may be empty cells or cells
with more than one position title in them. If your organization has
more than one specific position title in a cell, then there will
probably be some ordering of those position titles with respect to
their skill and competency profile. So the career path may contain
advancements to positions within a single cell. The minimum skill and
competency profile required to enter a cell at the lowest position is
work that still remains to be done. That will require a significant
effort and help from both the PM and the BA side. That discussion is
left for a future article.

A Deeper Look into the BA/PM Landscape

Since we now have a BA/PM generic position family defined and a career path for that family, Figure 1 takes on more meaning. An example will help. Figure 1 shows an individual whose current position is in the BA/pm Associate Manager cell. This person is a professional project manager with basic business analysis skills and competencies. This is a very common position. Recognizing the importance and value of having stronger business, their short-term goal is to have a position in the BA/PM Associate Manager cell. To do this, they will build a plan in their Professional Development Program (PDP) to accomplish their short-term career goal. Their PDP will focus on improving their business analysis skill and competency profile from that of a PM/ba Associate Manager to that of a PM/BA Associate Manager. The PDP for this person might contain the following strategies:

Experience Acquisition

  • Seek out project assignments that have more of a business analysis focus than they are accustomed to.
  • Support professionals who are more senior to you and have a business analysis skill that you need to improve to better meet current position requirements.

On-the-job Training

  • Look for opportunities to observe and support the business analysis work of BA/PM professionals
  • Take courses (on or off site) to enhance the business analysis skills required of your current position

Off-the-job Training

  • Take courses (on or off site) to add business analysis skills that will be required by your targeted position in the PM/BA Associate Manager cell
  • Look for opportunities to observe and support a professional practicing the business analysis skills you will need in your targeted position.

Professional Activities

  • Read books and journal articles on topics relevant to your targeted position in the PM/BA Associate Manager cell
  • Attend meetings and conferences offering seminars and workshops relevant to your targeted position in the PM/BA Associate Manager cellSecondLook1.png
    Figure 1: Using the BA/PM Landscape for a Short-Term Professional Goal in the same Position

In my experience with PDPs they tend to cover an annual planning horizon with at least semi-annual status meetings with a mentor, or as needed meetings that you will request.   

Figure 2 illustrates an example that is a little more complex. Here the short-term PDP is targeting a change from a position in the PM/ba Associate Manager cell to a position in the PM/ba Senior Manager cell. As you can see the Core, PM and ba skills profiles will be affected. The ba skills profile will be minimally affected only by the change of position level.

 

SecondLook2.png
Figure 2: Using the BA/PM Landscape for a Short-Term Professional Goal at a Higher Level Position

Figure 3 is a combination of the situations depicted in Figures 1 and 2. It illustrates yet another example of a more complex situation than is illustrated in Figures 1 and 2. Here the change is not only to a higher level position (Associate Manager to Senior Manager) as was the case in Figure 2 but also to a position requiring a broader and deeper business analysis skills profile (ba to BA) as was the case in Figure 1. A career change like this may take some time to accomplish. Not only will the person need to acquire additional experience to qualify for the higher level position, they will also need to increase their business analysis experience, and skill and competency profile, to qualify for the higher level position’s business analysis requirements. A better professional development plan might be to follow one of the two-step strategies below:

PM/ba Associate Manager -> PM/BA Associate Manager -> PM/BA Senior Manager

or

PM/ba Associate Manager -> PM/ba Senior Manager -> PM/BA Senior Manager    

The likely promotion opportunities may help you choose the better of the two strategies.

 

SecondLook3.png
Figure 3: Using the BA/PM Landscape for a Longer-Term Professional Goal at a Higher Level Position

Career Planning Using the BA/PM Landscape

A section of the PDP should be devoted to long range career planning. The BA/PM landscape is a tool that can aid in the planning process. Figure 4 illustrates a career path leading from a position in the BA Team Member cell to a position in the BA/PM Senior Manager cell. The CareerAgent System that I mentioned in an earlier article (A First Pass at Defining the BA/PM Position Family) included a decision support system that helped the individual plan their career path down to the position title level within the cells. It mapped out a training and development sequence leading from position to position across the BA/PM landscape until the final career goal had been reached.

 

SecondLook4.png
Figure 4: A Career Path from a Position in the BA Team Member Cell to a Position in the BA/PM Senior Manager Cell

As the plan is executed it will most likely change. Even the targeted position might change. There are several factors that will influence the plan and suggest revisions more compatible with the changing business environment and that offer more career growth and professional development opportunities.

A Call to Action

In the previous article (A First Look Under the Hood of the BA/PM Positin Family) I stated that this is a work in progress. I have participated in the development of similar structures for the IT professional but not for the BA/PM professional (or PM/BA if you prefer). Much remains to be done. I welcome a partner from the BA side to work with me in this challenging and valuable pursuit. It is my hope that I have launched this effort in a direction that ultimately will make sense across the entire BA and PM professional landscape. If you are interested in discussing a possible collaboration, you may reach me directly at [email protected].

Putting It All Together

In this article I have shown by example how the BA/PM landscape and BA/PM position family would be used in professional development and career planning.

The responses to the first five articles have been overwhelming. They have been both positive and negative. Being a change management advocate I am thankful for your interest but not surprised with your reactions. My hope is that we can continue the exchange. As always I welcome opposing positions and the opportunity to engage in public discussions. Your substantive comments are valuable. Criticism is fine and is expected but, in the spirit of agile project management, so are suggestions for improvement. Also in the spirit of agile project management, I am trying to find a solution to the career and professional development of the BA, BA/pm, BA/PM, PM/BA, PM/ba and PM.

I realize that I have taken a controversial position and in so doing have stepped out of my comfort zone and perhaps put myself in harm’s way. I do so intentionally. Through all of the earlier articles I hoped to get your attention and that has happened. In this and subsequent articles I hope to get you to start thinking about the care and feeding of a single BA/PM professional – one who is fully skilled in both disciplines. I have a very strong belief that there is a crying need for the BA/PM professional. As you dig deeper into the BA/PM through this series I ask that you approach my suggestions with an open mind and offer your ideas in this public forum.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

When is the BA’s Work Finally Finished?

Written by Cynthia Low on . Posted in Articles.

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 progresses, the BA should collaborate with the solution team (for example, development, procurement) to ensure that the agreed 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 their 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 will suit 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 that is being built that would be beneficial. This is especially likely where those processes will be affected when the solution is implemented.

Validate the Approved Solution

As each deliverable of the project becomes available, the BA must ensure that appropriate validations take place to be sure 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 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 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 developing internally) 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 for communicating the impact of the solution 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 in 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.

Copyright © Global Knowledge Training LLC. All rights reserved.

Jill Liles has been the Marketing Manager for Global Knowledge’s Business Analysis training courses for two years. Her background is in continuing education and non-profit marketing, and she graduated Summa Cum Laude from Peace College in Raleigh, NC.

This article was originally published in Global Knowledge’s Business Brief e-newsletter. Global Knowledge (www.globalknowledge.com) delivers comprehensive hands-on project management, business analysis, ITIL, and professional skills training. Visit our online Knowledge Center for free white papers, webinars, and more.