Business Analysis

How Much Of The BABOK Knowledge Areas Are About Work & Tasks?

As odd as it may sound, all six of the knowledge areas described on page 4 of the BABOK third edition start with a similar tone. There is an ever so slight divergence in Strategy Analysis but it is so slight that it is barely enough to mention. Just for those of you that might be curious, the Strategy Analysis knowledge area text description starts with "describes the business analysis work that must be performed", while the five others start with "describes the tasks that business analysts perform".

From last weekends pet friendly Jingle Bell run, Tanner is checking out that table over in the corner with doggie treats! 

Any seasoned business analyst will tell you that a requirement that contains the word “must” can be considered in a different category than the requirements that do not contain it. I know that I’m going down a bit of a weird path at the start of this narrative but I think it makes a little more sense when I get to the pastry bit.

The point here is that tasks and work are the cornerstones of BABOK knowledge area descriptions. So if you ever struggle with deciding what you can do on a particular day, picking up the BABOK could help define that for you. Even the most experienced business analyst can benefit from a refresher and the knowledge areas can be a great source of inspiration. 

Say that you have a complicated requirements package on a even more complicated project. You may have the nagging feeling in the back of your head that you are missing something. A method that I've used on occasion is to go down to the break room, warm up a pastry in the microwave, get a fresh cup of copy and browse the BABOK. Perhaps you are thinking that you could do more in the area of strategic analysis. Looking over the BABOK might give you insights that help identify what was troubling you or it can help you feel confident that you covered that area pretty well!

© 2016 Dwayne Wright

Should A Business Analyst Know How To Build Robust Project Schedules?

The requirements life cycle is directly tied to the project life cycle, there really isn't any way around that reality. If a project is not planned well, you can expect the impact to be felt in requirements gathering, requirements analysis, requirements validation and requirement change management. This could be one of the reasons why you see a significant rise in job opportunities that are titled Business Analyst / Project Manager. 

Came across this amazing bike sculpture on the Green River Trail! Took the opportunity for a "selfie" that looks like I'm riding with them!

Although many successful business analysts do not know their way around project scheduling tools such as Microsoft Project, I find that skill set very useful. In one project I worked on, the project manager built a MS Project schedule that clearly missed the mark in the requirement management area. That entire section literally didn't have one requirement task that was listed as a predecessor to downstream tasks or milestones. This was a circumstance in which I had to fight for my requirements schedule without being confrontational or combative. 

I believe that every business analyst should have a requirements management plan and work to have it submitted into the project documentation portfolio. That plan may or may not include a schedule, my strong recommendation is that it should. In the situation described above, I did the following:

- built a MS Project schedule for the requirement life cycle tasks
- rebuilt the project managers project schedule to include the above content
- setup each requirement task as a predecessor task where appropriate
- estimated the duration of requirement tasks with a goal to align with overall schedule objectives
- used color highlighting to show the critical path tasks as they pertained to requirements
- scheduled a workshop with the project manager to go over the content
- used a structured walkthrough method to go over my recommendations

I was very careful in my approach during the one-on-one workshop with the project manager. I had a high level of respect for her and didn’t want her to take my feedback as a challenge. Project managers have a tough job and my goal was to be a valuable resource for the project. Although I obviously felt a strong commitment to my feedback, I was prepared to defer and commit to the chosen path as a project professional.

This project manager was and continues to be an exceptional PM. She did incorporate many of my recommendations but that wasn't the most important thing she did. She scheduled another workshop with key team members and we went over it again. This opened up a valuable discussion and the team bonded a bit tighter that day. The schedules I created became a great way for the team as a whole to understand the requirements lifecycle and it paid valuable dividends as we marched towards a successful project completion. 

This is just one story and I hope it may have provided some insights for you. I welcome any comments you may have both positive and negative. 


© 2016 Dwayne Wright

Struggling With Business Rule Discovery - Jump In Use Case Design

In software development projects, business rules are either a constraint (legal, regulatory or organization policy) or a procedure traceable to some other operation. Remember, software systems are much like an environmental ecosystem. Any change can have affects on upstream or downstream operations in ways that are best discovered before the system goes live. 

A professional business analyst can and will perform classic elicitation methods to discover business rules and to validate them. However, business rules can be in the realm of tribal knowledge. Meaning that this critical information is often undocumented by the workgroup but used so often that they assume everyone else knows about it. Interview and workshop methods may miss critical business rules and the business analyst might not have enough time to employ observation techniques. 

Even if the BA is employing observation techniques for both requirement and business rule discovery, using use case design is an excellent method to facilitate the process. Use cases are a great way to find information dust bunnies. Sorry, I seem to be really into analogies in this piece. Dust bunnies is a term for the small clumps of dust & hair found under furniture and in seldom visited corners of a room. 

Just like how actual dust bunnies are harmful to electronics, these information dust bunnies can cause real harm if they are not taken care of before software deployment. Use cases are like small virtual deployments, it uses imagination to foresee how a new system will impact a process, actors and associated subsystems. 

© 2016 Dwayne Wright

Off The Shelf and Custom Built Requirement Management Tools

Requirements lifecycle management can be a difficult endeavor but the ability to leverage a well crafted tool to meet those needs can take a significant amount of “the sting” out of the process. This is because the tool can be loaded with automatic processes that adhere to the organization’s goals and associated business rules. These automatic processes can vary wildly from one package to the next, in particular the difference may lie between off the shelf and custom built tools. 

If your organization lacks tightly defined business rules regarding the requirements lifecycle, an off the shelf solution may be able to provide that for you. Off the shelf packages that lack significant customization will require that your business adapt to the way it was designed to operate. That might sound a bit strong but I assure you that it is true. The thing is, it is likely that isn't a big deal if your organization is starting from scratch in regards to requirements management. That structure could be the strongest asset that package will bring to your organization. However, this does mean that you may have significant gaps between what the package offers and the long term needs for your organization.

If your organization has significant business rules or external agency regulations it must follow in regards to requirements management, a custom built solution may be the best avenue for you to pursue. A custom built solution doesn't necessarily mean that you will have a pocket full of magic when it is deployed. Based upon the associated complexity needed, a custom solution may have significant drawbacks to consider. This can include but not limited to cost, time to build, resources for testing and the possible need to build a training component to insure a beneficial organization change experience. 

There is even the possibility of a hybrid solution that blends off the shelf with customization. A solution may offer significant customization and how that capability is used may move it more towards a custom solution. It becomes a custom solution with a great head start benefit from a base originating from an off the shelf frame. This may end up having the benefits of both options and/or the disadvantages of both. 

The funny thing here is that a seasoned business analyst can certainly help in this area and I'm talking about outside of the subject matter expert domain. A business analyst will have tools, techniques and experience in evaluating these options. They can present the findings of a detailed analysis that looks at the big picture and delivers information to help decision makers make an informed decision.

© 2016 Dwayne Wright

Competing Expectations: The Project Manager & Business Analyst

The role of the business analyst is on the rise and often encroaches upon areas traditionally within the project managers domain. Although this conflict is actualized between those two roles, the root cause is generally found higher up in the organization chart. Both project managers and business analysts work very hard to meet the expectations of their superiors. Often it is the competing expectations that are causing the conflict and not a personality clash between the two roles.

When an organization places a project manager within a project, they are expecting that individual to deliver within the established budget and schedule. Simply put, project managers will manage scope creep because it is a legitimate threat to schedule and budget. A project manager that delivers a project within budget/schedule constraints with additional scope included is generally considered a great project manager. Yes, there are exceptions to this but not that many! In fact, unless that extra scope that gets squeezed into the project introduces new company risk, that project manager might expect a promotion for delivering more for less than expected.

A business analyst is expected to deliver significant value after the project closes. They identify areas in which more revenue can be returned or less costs incurred based upon value multipliers. A value multiplier would be the number of times the value can be triggered and the value amount. For example, a new feature saves an individual 2 minutes per use, it is used by 10,000 people at an average of twice per week. Exploring the value math, 

• triggered 20,000 per week (10,000 people x twice a week)
• 1,040,000 minutes per year (20,000 x 52 weeks)
• 17,300 hours per year (1,040,000 / 60)
• 70,000 average salary = $35 a hour
• $605,500 value annually (17,300 x 35)

The next steps a BA would perform include determining the costs of the new feature, perform a cost benefit analysis and associated payback period calculation.

If a business analyst wants to include an out of scope requirement in their package, it is because they feel the downstream value greatly exceeds the additional cost and project schedule impact. When a business analyst wants to submit a scope change request, the first obstacle they have to overcome is the project manager. Although a project manager should not have the authority to deny a change request submission, many will make the attempt to do so. They certainly should have a voice in the approval and I would recommend that all business analysts strive to have PM approval before submitting the request.  

The key to avoiding or resolving this fundamental expectation gap is knowledge. At the fundamental layer, a project manager should not look at scope increase supported by the business analyst as a threat. In fact, any project that doesn't undergo some scope modification is generally an unhealthy anomaly. This is particularly true in software projects but it holds true for all projects. If a project looks to be adhering tightly to the scope identified in the early business case / charter documentation, then it is likely that dozens of a significant value opportunities are being lost. 

© 2016 Dwayne Wright

How Many Times Have You Fallen In Love Because Of Nonfunctional Requirements?

When attempts are made by a fresh business analyst to elicit or document nonfunctional requirements, the attention often shifts back to the functional requirements.  To them, the nonfunctional requirements can be like those aunts and uncles at the family reunion that you don't seem to know much about. You know they are family but you struggle in attempts to start up a conversation with them. 

Many times, nonfunctional requirements and constraints are considered so similar that an analyst will simply group them together with the same label. In those cases, the label chosen is "Constraints", simply because the word is easier for most stakeholders to understand. I've heard it explained that most constraints are written from a negative context such as "the product can not, should not, will not". Requirements are best written in the positive voice including the verbs of can, should and will. 

One of the most common descriptions of nonfunctional requirements are needs a user must have but they may not realize it. I've seen the importance of nonfunctional requirements compared to products from Apple computer and include the branding, presentation, size and even customer service features like the Genius Bar or glitzy stores in the mall. In most cases, these attributes do not help the product function better but still make them more desirable, at least to some, than functionally equal competitors. 

How many people do you think fell in love with an iPhone but that person spent less than one hour with it? It is possible to appreciate many of the functional capabilities of such a product but you know many just loved the idea of having one. In many ways, the lackluster success of the Apple Watch could be attributed to the fact that the lack of functional features outweigh the nonfunctional sexy aspects of the device that Apple continues to bombard you with in their marketing attempts.

Quality, or the perception of it, is often one of the most powerful nonfunctional requirements in determining if a product is a success or a failure. Some less sexy attributes of nonfunctional requirements include security, scalability, availability, reliability and even attractiveness. As you might have guessed, nonfunctional requirements are more difficult to specify accurately and can equally challenging to test. This is because they often are measured differently by the individual making the specification, test or measurement. 

When writing the acceptance criteria for a nonfunctional requirement, you will want to include a description of it, how to measure it, the lowest acceptable value, the target value and the expected value. 

A popular example of nonfunctional requirement measurements comes from the technical arena in the form of a SLA (service level agreement). A good SLA will contain strong KPIs for a significant collection of nonfunctional requirements and is used as a core document for funding resources to ensure that nonfunctional requirements fall within acceptable parameters. 

Properly written acceptance criteria for nonfunctional requirements in a SLA should allow leadership to effectively manage and optimize the product/service to meet the spirit of those expectations.

A Different Take On Gamification And Project Management

Back in 2010, I took a three month job with Wizards Of Coast and that turned into a three year journey. If you are not familiar with the company, they make the popular Dungeons And Dragons role playing game and the insanely popular Magic, The Gathering collector card game. I was hired to help update a database tool that transformed editorial content about mystical worlds into components to support a subscription based online resource for serious gamers. 

Pulled this from their website in the about page. It was taken back in 2013 and I'm in there, can you find me? 

Basically, Dungeons & Dragons is a weird hybrid of story telling and group game play. The storyteller, called a Dungeon Master, facilitates the game play by unfolding the story as players take turns. Based upon decisions made by players, the roll of dice and sometimes a flip of a card, both the story and the game can branch into different directions. 

So the group of characters which the players have created bring unique skills to the effort. Additionally, each has a set of tools they start off with and tools they pick up along the way. They set off on a quest and have to coordinate efforts, communicate effectively and use problem solving skills to survive. Many times, the quest is actually a series of individual efforts that can span days, weeks or even months. Many times the players are prepared for the unfortunate events that unfold and sometimes they are not. Sometimes you loose characters along the way and that is considered unfortunate and can seriously affect the overall effort. 

Are you getting it yet? No, not the premise behind D&D. The project management angle in regards to this narrative, are you getting it?

Quest = Project
Characters = Team Members
Decisions/Dice/Cards = Decisions/Outside Factors
Magical Characters = Team Member Skills That Look Like Magic
Magical Tools = Software Tools
Coordination/Communication/Problem Solving = Coordination/Communication/Problem Solving
Unfortunate Loss Of Team Members = Unfortunate Loss Of Team Members 

When I was first introduced to the game during my first week, I had an odd feeling that I had played this game before!