Skip to main content

Random Thoughts on Service Management

  • Google suits my impulsive mind perfectly and is a great first step in discovering whether an idea is “out there” yet. Yesterday I searched for “service-oriented business analysis” and was not disappointed with the results – only seven hits, but this one points to an excellent six-part treatment of SOA and BA.

  • Can a senior BA really be skilled in all aspects of the solution life cycle? As I ponder the scope of BA, I grow more convinced that business requirements elicitation alone could be a fulfilling and challenging career.
  • And speaking of elicitation, if you peel back the first layer of the “agile business analysis” onion, one of the things you would see is agile elicitation. What does that mean in terms of the day-to-day relationship between the BA and the business stakeholders? Would it border on pestering? (Just kidding, kind of….) But what a magnificent way to help drive change management into the core of that relationship.
  • Service modeling in the true SOA sense takes a common concept – refactoring – and applies it to a broader context – the enterprise. There are clearly application refactoring techniques that can be leveraged in an organization’s SOA, service modeling, and BPM initiatives.
  • And speaking of SOA and services, their value arises out of what I have always believed to be the most important and fundamental notion coming out of the Object Oriented fury of the 1990s: that of encapsulation. Inheritance? Polymorphism? Frequently, copy-and-paste is the better technique. But nothing beats encapsulation – it’s the heart of separating the What from the How.
  • SOA and ITIL v3 are a perfect match – BAs involved in business architecture and IT-based solutions would do well to become fluent in both.
  • And speaking of the What vs. the How, it is only a matter of time before nearly every discipline in the enterprise will be modeled as a service, with service level agreements, metrics and measures, reporting and reviewing, and a context of continual service improvement and alignment to targeted business outcomes. Today the focus is on IT via ITIL, because IT really needed to get its house in order ever since the PC and LANs in the 1980s, client/server in the 1990s, security in the 2000s, etc. It will be very interesting to witness the extent to which the practice of ITIL within an enterprise will influence the application of the concept of services in non-IT disciplines.

I Don’t Have Time to Manage Requirements; My Project is Late Already! Part II

Now that we have looked at the framework for requirements management, let’s delve deeper into requirements planning.

The Requirements Management Plan 

Planning the business analysis work effort is part of the overall effort to plan the project, and the resulting Requirements Management Plan becomes part of the project management plan. Below is a table with some of the key planning activities, the sub-processes associated with each, and the final deliverables that are produced. As stated earlier, these deliverables are rolled into the requirements management plan, which in turn, is a subsidiary plan within the overall project management plan.

Because of the interrelationship of the project and the product, of the project manager and the business analyst, most of the activities below, while focusing on the product or activities to produce the product, are part of the larger project. The effective project manager, in planning for the whole project, seeks input from a variety of team members to create scope, schedule, and cost baselines. One of these team members is the business analyst, who provides input on the business analysis phase or phases. In other words, the business analyst plans which activities will be needed to define the product requirements completely and correctly. The information from business analysis feeds into the overall project.

Below is a table which expands on the activities in the knowledge area of business analysis planning and monitoring, the processes within the broader tasks, and the key deliverables that are output from these processes.

idonthave1.png

 

Exhibit 3 – Requirements Planning Activities and Deliverables

It is helpful to remember that each of these activities and sub-processes should be considered and performed, although not with the same amount of formality. For example, identifying project roles can take place in a formal, facilitated session with cross-functional representation, or it can occur when the project professional informally touches base with a limited number of stakeholders. Likewise, the deliverables may be permanent and stored in a repository or they can be temporary, a by-product of an informal conversation. In the latter example, the deliverable may be produced on a whiteboard and erased at the end of the discussion, kept in notes until the end of the project, or archived indefinitely. What is important is that these decisions be made purposefully and before the execution of business analysis has occurred.

Clarifying Roles

One of the first tasks in requirements planning is completing stakeholder analysis, during which time it is important to clarify the project professional’s role and associated responsibilities. Because of the interrelationship of the project and product, the roles of project manager and business analyst tend to blur in some organizations and on some projects. Here are several considerations to help clarify these two roles:

  • The difference between the function of managing the project and that of managing both the requirements and the business analysis phase(s). Although the same person can certainly manage both functions, they are different and the associated roles are also different. Skills required and characteristics of effective performance differ for each role, so giving thought to each during stakeholder analysis is important. For example, it is even more important for the project manager than the business analyst to have human resource management skills, and it is even more important for the latter to be an expert facilitator.
  • The consultative nature of the project professional’s role. In establishing roles and responsibilities it is important to view the project professional as a consultant who makes recommendations, rather than either as an owner or as an order-taker. One of the required skills is the ability to influence without authority. A responsibilities assignment matrix, such as a RACI, can help with this clarification. 
  • The importance of distinguishing between requirements management and product ownership is also critical. We need to remember that managing requirements does not mean owning them. When clients are not available, it is rarely in the best interest of the project to continue without executive and business client support. Since it is the sponsor who has a business problem needing a solution, the sponsor needs to assign people who can define what they want in a timely manner. The project professional can have input and can certainly make recommendations, but the final decisions and acceptance of the requirements need to rest with sponsors. Therefore it is necessary to clarify the sponsor’s role as the ultimate owner, even if they have chosen to designate a day-to-day project owner. 
  • Finally, project professionals need to keep asking why the stated business problem is worth solving and to explain why it’s in the sponsor’s best interest to provide available resources who can define the requirements that will solve the business problem.

The next article in the series explores the consultative nature of the project professional and provides tips for negotiating to ensure there is enough project time for requirements management.


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com.

I Don’t Have Time to Manage Requirements; My Project is Late Already!

An Overview

For those of us who have been given imposed deadlines that often seem arbitrary and unreasonable, managing requirements is one of the last things we want to do on a project. We worry about getting the product built and tested as best as we can. And we feel fortunate to gather any requirements at all. However the lack of a well-managed requirements process can lead to common project issues, such as scope creep, cost overruns, and products that are not used. Yet many project professionals skim over this important part of the project and rush to design and build the end product.

This is the first in a series of articles providing an overview of requirements management. It emphasizes that the discipline of requirements management dovetails with that of project management, and discusses the relationship between the two disciplines. It describes the requirements framework and associated knowledge areas. In addition, it details the activities in requirements planning, describes components of a Requirements Management Plan, and explains how to negotiate for the use of requirements management tools, such as the Requirements Traceability Matrix to “get the project done on time.”

The Case Against Requirements Management

It is not uncommon to hear project professionals and team members rationalize about why requirements management is not necessary. We commonly hear these types of statements:

  • “I don’t have time to manage their requirements. I’m feeling enough pressure to get the project done by the deadline, which has already been dictated. My team needs to get going quickly if we have a hope of meeting the date.” 
  • “Our business customers don’t fully understand their requirements. We could spend months spinning our wheels without nailing them down. I doubt if all the details will emerge until after we implement!” 
  • “My clients are not available. I schedule meetings only to have them cancelled at the last minute. They don’t have time. They’re too busy on their own work to spend time in requirements meetings. And my clients, the good ones, are working on other projects, their day-to-day jobs, fighting fires, and their own issues.” 
  • “Managing requirements, when they’re just going to change, is a waste of time and resources. It creates a bureaucracy. It uses resources that could be more productive on other tasks, such as actually getting the project done!” 
  • “They don’t think we’re productive unless we’re building the end product. They don’t want to pay for us to spend a lot of time in requirements meetings or doing paperwork!”

For many requirements management equates to bureaucracy and “paperwork,” because the discipline has not yet stabilized and evolved. The International Institute of Business Analysis (IIBA) in their body of knowledge, the Business Analysis Body of Knowledge (BABOK), establishes a requirements framework for the discipline of requirements management.

This series of articles discusses requirements management, emphasizing the planning and the requirements management plan.

Requirements Management Overview

The Project Management Institute (PMI, 2004, p 111), the International Institute of Business Analysis (IIBA, 2006, p 9) and the Institute for Electrical and Electronics Engineers (IEEE, 1990, Standard 610) all define a requirement as a condition or capability needed to solve a problem or achieve an objective that must be met by a system or system component to satisfy a contract, standard, or specification.

Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. The output from requirements management is a requirements management plan, which on large projects can be a formal set of documents with many subsidiary plans. Examples of subsidiary documents are a business analysis communication plan, metrics for measuring business analysis work, key deliverables and estimates for the business analysis work effort, and many more. On smaller efforts this requirements management plan can be an informal roadmap. In either case, it is subsidiary to the overall project management plan, created, executed, controlled, and updated by the project manager.

Below is an exhibit showing the relationship between the requirements management plan and example set of plans that are subsidiary to the integrated project management plan. As indicated, the requirements management plan is incorporated into the project management plan, and all the subsidiary requirements management plans are incorporated into the subsidiary plans, within the overall project management plan. We will have a deeper look at requirements planning later in this series.

idonthavetime1.png
Exhibit 1: The Requirements Management Plan in Relation to Project Management

If care isn’t given to planning business analysis activities, the entire project could go awry. Lack of requirements management is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects. (Software Engineering Institute (SEI’s) Square Project updated 5/12/05).

In the upcoming articles of the series, we’re going to focus on requirements planning. But, it is also important to understand the overall requirements management framework, which is based on the BABOK. The remaining parts of the series includes: Part II – BABOK Overview, III-Requirements Planning, IV-The “Right Amount” of Requirements Management.


Elizabeth Larson, CBAP, PMP and Richard Larson, CBAP, PMP are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.

Documents; The Neglected Side of Business Information Automation

Many organizations today are looking inward to streamline their processes and increase efficiency. Traditionally, much of their emphasis has been focused on developing or acquiring high tech business automation solutions, while improvements regarding business processes and the documents that flow through them have been largely ignored.

People, processes, paper and technology must work together in an environment that promotes collaboration and accountability in order to maximize effectiveness and efficiency. Most organizations forget to include all relevant information involved in a business process while working in a digital environment.

Most of it is locked and hidden away in unstructured documents – email, diagrams, notes, spreadsheets and other amorphous silos of information. All are important pieces when preparing the foundation of a business decision and should be quickly accessible to everyone involved.

All too often, an electronic Document Management (eDM) solution is implemented and placed at the end of the process, performing only as an archival virtual filing cabinet. Following the Six Sigma methodology of DMAIC – Define, Measure, Analyze, Improve, and Control – a business analyst can help their company place the eDM initiative at the front of the process, as paper and electronic documents are received, so that eDM technology may benefit and improve the entire business process for significantly greater value and return-on-investment.

Define and Measure: The Significance of Documents

Fundamentally, there are many types of documents considered as evidence of a business transaction. Although this information may be transcribed into an organization’s database, there are legal/compliance reasons that companies must protect, retrieve and produce these documents on a routine or on-exception basis.

Much of the manual daily business activities involve handling and preparing documents for processing, using database applications as well as when performing operational tasks. Unfortunately, companies today are unaware of the eDM systems potential and simply file paper or electronic images of these documents in ways that make accessing and working with them both cumbersome and time consuming.

Common Problems in Companies Today

  • “Is the document I need an email, fax, word-processor, spreadsheet, drawing, photo or paper and whose file is it in?”. After determining it is in Sarah’s possession – “Sarah is on vacation and I don’t have a key to her desk or her email/fax/computer password to find it now”. 
  • “I can’t find/read your fax, please resend it” A terrible thing to say to your customer. This is done every day in many companies, not just once, but more than once to the same customer for the same fax! 
  • When auditors request that all materials related to a particular account be collected, it can be a nightmare to try to bridge all the different paper, email, fax and disk filing silos to search. 
  • How does a company ensure privacy compliance when an email on the subject may have been electronically forwarded and replied to many different individuals/email boxes, creating and duplicating potentially sensitive data? How can you be sure the data is fully-removed or complies with retention policies? 
  • “I have worked here for five years and I’m proud to say I’ve never deleted an email.” Microsoft Exchange and similar email systems were designed to communicate messages — not to archive emails and attached documents forever.

It is important to note that traditional “paper-shuffling and frantic-file searches” also apply to electronic files such as email, faxes and digital documents.

Analyze and Improve: Addressing the Document Information Gap

We begin addressing the document information gap by identifying untraditional document types involved in a business decision, which are needed in the overall design of the enterprise’s document management system. The establishment of a common Document Repository eliminates information silos, allowing documents to be easily searched for and shared by order of relevance – regardless of their origin, paper, email, fax, office-tool generated, etc.

A well designed eDM solution establishes the foundation needed for an efficient electronic Workflow (eWorkflow) solution to help improve and streamline business processes. In order to maximize the potential of the eDM solution, the business analyst must take steps to document a clear understanding of the current processes and goals. Then it is possible to look objectively at the opportunities to formulate a clear vision for the improved and automated business processes.

Once this vision has gained consensus of management and staff, today’s eDM solutions make it possible to prototype eWorkflow solutions that model the integration of eDM systems with actual business processes. These solutions provide higher-level workflow specifications appropriate for both technical and non-technical business analysts.

  • Visual eWorkflow Modeling is easy for the business analyst to define and for the impacted staff to understand. The visual eWorkflow process models can then be prototyped and tested allowing the business analyst and staff to understand the process and see it in action. This interactive experience allows each process to be verified and further refined by rapid iteration until it is right. 
  • The business analyst is typically able to simplify processes, eliminate steps that add no business value and reduce the number of required processes by focusing on the mainstream processes. As a result, the eWorkflow designs are likely to have fewer exceptions 
  • However, since exceptions are a normal part of business, the eWorkflow solution provides standardized methods and tools for handling them such as: 
    • Auto-Reroute & Alert Mechanisms that are triggered by a business rule violation or time-limit timeout or specified condition that take a specified action, route to a pre-defined general exception process or generate an alert-message notice via email. 
    • When more than one document must be present before performing the next eWorkflow step processing, the order in which the documents arrive at the workflow step is not important, but once all required documents are present and available processing can continue at the next step. Should too much time elapse, and one or more required documents have not appeared, then an auto-reroute or alert mechanism is triggered to insure that the exception is properly handled.

Measure and Control: Automated Process Information Metrics

New real-time design and control mechanisms are being introduced in today’s advanced eDM/eWorkflow solutions: 

  • Business analysts are able to create Visual eWorkflow and staff can easily understand and use the improved business processes being defined. 
  • Users working under an eWorkflow solution:: 
    • Can easily see their assigned work for one or many different types of processes in their browser window. o Provide a heads-up display of key procedural steps to be followed when working on a particular document. 
    • Require no programming knowledge to define business rule routing logic, so that work can effectively be tracked and delivered to the right people each time. 
  • Operational supervisors can use the visual representations of eWorkflow to monitor in real-time, information regarding individual processing performance statistics, number of assigned resources, identify process bottlenecks and for each process/task view the number of work-items:
    • Completed 
    • In-Process 
    • Pending Processing
      documents1.png
  • Advanced functionality can help supervisors reassign resources allocated to a process on-the-fly: 
    • For a temporary period or permanently o Staff may continue to serve previously-assigneddocuments2.png processes as well as the new assignment 
    • Unlike traditional, workflow that routes to specified workstations or individuals, modern routing is done to defined processes where User-Roles or Resources can be assigned to specified processes where human intervention is needed. 
  • Extensive on-demand reports are defined and others may be created with high-level report generation tools by business analysts and/or knowledgeable operational staff.

Summary

Despite the widespread usage of database applications, business processes are typically poorly documented and have many processing exceptions, ad hoc and inconsistent procedures. To some extent, this is due to the fact that documents have been neglected in the overall design of information systems.

By taking advantage of the many new advances in eDM and eWorkflow technology as well as the steep declines in the cost of computers, storage and networking, it is practical to consider integrating documents and business applications into functionally-complete business process automation systems.

Many of today’s eDM solutions are web-enabled and allow documents to be efficiently captured, shared, processed, stored and displayed from virtually anywhere an Internet connection is available. Tight integration of eDM with business process, central access for all document stakeholders, and enhanced real-time business process controls are just a few of the gains that can be realized when document automation is incorporated into the overall design of business systems.

Note: The iDatix iSynergy electronic Document Management (eDM) and Progression electronic Workflow (eWorkflow) solutions have been successfully used by Point North Consulting to address these issues and provide the described functionality presented in this paper.


Mark Crandall is a Senior Director and the President of Point North Consulting in Orlando, FL. He has more than fifteen years experience with business process improvement and information management. Mr. Crandall has a proven track record gathering and analyzing requirements, translating requirements into efficient design implementation projects, and managing the initiatives through the development life cycle to achieve streamlined business processes. Before forming Point North Consulting, Mr. Crandall was the CEO/Owner of Crandall Technologies, a consulting firm in Gainesville, FL (1996-2000), serving small to medium sized businesses with a focus on Business Process Re-engineering, Technical Architecture, Data Mining, and Business Intelligence.

Mr. Crandall was educated at the University of Florida, studying Materials Science Engineering and Business Administration as an undergraduate. After being accepted to University of Florida’s Masters Program in Decision and Information Sciences (DIS), Mr. Crandall was invited to participate in the selective Ph.D.program in DIS. He completed the coursework for the degree, but opted to enter the business sector to consult small and medium-sized businesses full time.

Will PMI Agree that BA Must Precede Projects?

Behold the world’s shortest BA column (well, for me so far, anyway):

We have been discussing the great challenges to BA that I listed a few months ago.

Last month I dumped my own idea – that of having professional recognition for BAs at the level of accountants and attorneys. Not having it or having it – either way it is a great challenge for the profession (for now, we hide, not knowing what to do).

This month, I make the following points about PMI and IIBA cooperation, the second great challenge:

Many PMPs, upon first meeting a CBAP (myself) say: “I wish they would turn you guys loose before management just dumps some of the “projects” (actual word was not projects) they dump on us!”

Point well taken – it is a lot easier to make project estimates and plans when decent scoping and some due diligence (requirements and stakeholder investigation) is done up front.

When things do change, they are likely to be less radical, or if radical, they tend to pay of way better for the trouble taken to discover them (always remember that every project is a “team PhD” research effort, and change can be good when learning leads the way).

It is not fair to dump on PMPs. It IS dumping when a list of what Ivar Jacobsen calls “requirements assertions” gets laid on a project manager with a budget and a deadline. I get to say this because usually the PM dumps it on me (the BA), so I know, I know.

I acknowledge that this approach does not violate the rule of “you can tell me how fast, you can tell me how much, or you can tell me how good – pick any two”.

It doesn’t, because management only tells how long and how much – they typically DON’T tell how good, they just pretend they did, so they can complain and blame when they don’t get what they “wanted”.

Finally – how the HECK does anyone do earned value, when they aren’t even sure what anything is worth?

I call on PMPs to acknowledge this pre-project “analysis” gap, and to support BAs in the important task of filling it.

Don’t go crazy – not every project is worth a business case, and doesn’t that say something right there?

Let me know if you agree.