Tag: Planning

AI and the Digital BA—What’ It All About? Part 3

Written by Elizabeth Larson on February 27, 2020. Posted in Articles.

This is the last of a three-part article written with answers to some of the most frequently-asked questions I get about artificial intelligence (AI).

In Part 1, I addressed some common terms and issues related to AI as it is used in a business context. In part 2, I focused on the various roles that BAs play on AI efforts. In this article I will discuss various subjects like the need for AI translators, the importance of AI governance, and the digital PM. As with Parts 1 and 2, I will use a Q/A format.

Why is the role of AI translator so important?

Recently there have been numerous articles in journals like Forbes and Harvard Business Review (HBR) about the need for an AI translator role, someone who acts as a go-between between the organization’s data scientist and strategic decision-makers. These articles don’t mention the BA specifically, but their descriptions are consistent and describe a role that BAs have routinely played—that of ensuring that business stakeholders and technical staff understand each other. I think the AI translator is a perfect role for any experienced BA. Data scientists need to understand the strategic direction of the organization, the business need for the initiative, and the related business rules that will be required on many of the AI systems. Business stakeholders need to understand the impacts of their decisions.

In the early days of AI, it was not uncommon for data scientists to guess at the business rules and make AI-related decisions themselves. This did not go well, as documented in Computer World.[i] The next phase was to have data scientists get input directly from the business. This, too, did not go well. So some organizations have introduced an intermediary role—the AI translator. They understand that they need to have someone who understands the importance of business input and who can also speak comfortably with the data scientists—a translator role. That’s where the BA comes in. We’ve always been translators. Translating the requirements into designs and back to ensure stakeholders get the functionality they ask for and really need. Yes, this is a perfect role for the BA and one that can greatly contribute to successful AI projects.

How much governance is needed on AI initiatives?

Many of the challenges on AI initiatives are no different from those on other projects. In a survey published in Information Magazine in July 2019, respondents included these factors as the major challenges:[ii]

50% – Lack of leadership buy-in
49% – Lack of metrics, especially surrounding data (bad data, ownership, etc.)
37% Internal conflict
31% Time required to implement (takes longer than expected)
29% Unexpected costs

What do these factors have to do with governance? Each one directly relates.

Executive buy-in. Among other things, no executive buy-in makes it almost impossible to reach consensus on the need for and nature of governance itself.
Data metrics. Governance guides such metrics as how accurate historical data needs to be.
Internal conflict. Governance establishes guiding principles around conflict, how it will be resolved, and by whom.
Time and cost overruns. Project governance will help such things as keeping projects on track, how and when to communicate when they’re not, and even what “longer than expected” means, so forth.

The article goes on to suggest that in order have successful AI initiatives, organizations need to hire data stewards to manage and coordinate the organization’s data. The data steward would be a steward in the real sense of that word: someone to manage, administer, and generally take care the data. In order to manage and administer, this role needs to help the organization determine what that governance will work and then to be responsible for its governance. Sounds like a BA!

In a podcast, cited in Harvard Business Review (HBR) in August 2019, De Kai and Joanna Bryson join Azeem Azhar to discuss the importance of governance on AI initiatives.[iii] They define governance as coordinating resources involving both internal AI modules and humans. They suggest that there needs to be an independent, oversight group with the authority to apply agreed-upon governance, and I think the seasoned BA is in a perfect position to facilitate this group.

Is there such a thing as a digital PM and if so, how does that role differ from a digital BA?

Digital BAs are similar to all BAs in that they do BA tasks, use BA techniques, and need the same BA competencies (see Part 1). Likewise, digital PMs do PM tasks, use PM techniques, and need PM competencies. They work with the sponsor to charter AI projects and help organizations implement them. Although not yet a common role or title, having someone with experience managing AI projects can be valuable to organizations. Again, they’ll still do their tasks and use their techniques appropriate to PM work, but being a PM on an AI project and coordinating all the resources entailed on such an initiative will most certainly require a healthy working knowledge of AI.

Another way to look at digital PMs is that they use AI systems and tools to manage AI projects. In an article in Forbes Magazine on July 2019, the author focuses on the use of automated AI systems and tools to help digital PMs manage their projects.[iv] He says, “AI, with its unique ability to monitor patterns, is a capable assistant to PMs.” In addition to helping with the routine admin tasks, AI can provide all kinds of predictive analytics. AI tools can look at hidden complexities and all the moving parts inherent in a complex project or program and predict areas of concern, from project slippage to team members behavior and more.

The digital PM, then, is one who not only takes advantage of AI tools to do a better job of managing projects, but also has enough AI expertise to manage complex AI projects.

Does “digital” have to be related to “AI?”

In the past, the term “digital” was used broadly. It referred to any digital project, like development of a website, digital marketing, or developing the organization’s presence on social media. Nowadays the term is generally used to refer to “AI,” which encompasses all things related to machine learning, predictive analytics, and data mining. More recently the terms “AIs” and “AI systems” are also commonly used.

I hope you have enjoyed this three-part series. Look for more AI-related content in the future.

[i] https://www.computerworld.com/article/2484224/12-predictive-analytics-screw-ups.html, Robert Mitchell, July, 2013

[ii] https://www.information-management.com/opinion/data-governance-in-the-age-of-ai-beyond-the-basics, Data Governance in the Age of AI, Gienna Shaw, Information Magazine, July 19, 2019.

[iii] https://hbr.org/podcast/2019/08/governance-in-the-age-of-ai, Podcast, De Kai and Joanna Bryson

[iv] https://www.forbes.com/sites/cognitiveworld/2019/07/30/ai-in-project-management/#195242a6b4a0,, Forbes, Tom Schmelzer, July 30, 2019

Mind Maps for Business Analysis

Written by Jenny Quillian on October 18, 2019. Posted in Articles. 74 Comments on Mind Maps for Business Analysis

The purpose of this article is to demonstrate the use and benefits of Mind Maps for business analysis.

The 5W mind map uses the journalists’ five questions (Who, What, Where, When, Why) plus How to provide a template for a business analysis guide that can be used through the project lifecycle.

This technique is the first action I take for every new project, giving me a project overview that is then used as a check list and visual reminder during the course of the project. I use a free download version, but there are many mind mapping tools available and the paid versions offer more sophistication for presentations and integration with other project tools. (The mind map tools provide the ability to embellish your view with markers, images, colors and labels, but beware of drowning your big picture in a pool of emoji’s).

The diagram below shows the 6 major topics, and the initial round of sub-topics for each. The choice of sub-topic may vary with your project or your own area of responsibility.

USAGE BY KNOWLEDGE AREA

The mind map will grow and change during the course of the project and can be used under each of the BABOK knowledge areas as follows:

Business Analysis Planning and Monitoring
- At the start of each project, create a new mind map to organize and coordinate plans for the analysis tasks
- Add information from the project proposal to each topic
- Use the mind map tool to expand the sub topics as knowledge is gathered
Strategy Analysis
- Identify stakeholders and project partners under Who
- Record the high level business case under Why
Elicitation and Collaboration
- As requirements are gathered, add the high level business requirements and business rules under the What topic
- Record sizing and usage estimates against Who, How or What
Requirements Lifecycle Management
- Use the mind map during the course of the project to maintain focus on the high level requirements and to reinforce relationships between and justifications for requirements
- Use to analyze proposed changes
- Print out the mind map and pin to your wall or the project war room for all to see, especially during team discussions when members need to be anchored
- Refer to the mind map when developing presentations to stakeholders and project teams to maintain consistency over long projects
- Update the mind map during the course of the project, maintaining version numbers
Requirements Analysis and Design Definition
- Validate the requirements against the other project topics
Solution Evaluation
- Identify key aspects of the solutions and delivery methods under How
- Record implementation locations and delivery sites under Where

USAGE BY TOPIC

Each topic provides an opportunity for the BA to start shallow and take deep dives. Add all findings as you go – but do not hesitate to remove or edit as new facts or requirements are discovered.

Who – Stakeholders and Project Partners

The key stakeholders of the proposed system should be identified in the project proposal, but stakeholders are also uncovered during the life of the project. An example is downstream consumers of the product or data being delivered. User estimates can be noted against active and downstream users.

Making a note of the executive sponsors and influencers serves as a flag to follow up when there is an organization change or an executive mind shift. How will that affect your requirements? The BA should be aware of other partners such as Finance, delivery team, and the planned support team as potential influencers of the system requirements.

What – Requirements and Business Rules

Detailed requirements and user stories should be left out of the mind map, but they should map back from your requirements management tool to the mind map. The requirements in the What topic serve as a guide and constraint on the detailed requirements. There should be sufficient information so that the mind map is a stand-alone overview for when you are faced with an executive in the elevator asking what this project is about.

Where – Locations

The Where may prove to be not significant for a particular project, but including this in your initial template provides the opportunity to consider first then ignore – rather than ignoring first. Will the infrastructure be hosted in a public cloud or in-house servers? Will there be international users? Will the support be local or outsourced. The requirements must cover these variables. The delivery variables

When – Project Timelines

Making a note of the high level project timelines at minimum completes the overview of the project, but this branch may also include requirements analysis plans, sprint plans, and/or key business event dates.

How – Solutions and Methods

The Business Analyst is not responsible for technical solutions or project methodologies, but these may have an impact on requirements, and therefore the BA should be aware early of technical decisions such as COTS or Build, In-house or Outsourced, Agile or Waterfall. Record just enough information to show how the technical project decisions support the requirements. Sizing estimates should be recorded here because the technical solution should be compatible with the expected traffic and data volume on the system.

Why–Business Case

Recording the high level justification for the project provides another guideline reference for the business analysis work, and red flags during requirements analysis.

BENEFITS

The following section lists benefits from using mind maps for project and requirements management. In addition, I find them just fun to use. I was hooked on mind maps from the day our new Director introduced himself to the team through a colorful and informative mind map of his resume and interests.

Generate discussion and ideas. The loose structure of the visual and the flexibility of the software work together to open minds and to overcome reluctance to offer ideas and changes.
Multiple perspectives. The mind map shows horizontal and vertical perspectives. The drill-down design allows viewers to see big pictures and their underlying details in a single view. Discussions can go down rabbit holes into the detail but the presenter has a tool to bring them back to the shared big picture.
Highlight relationships. The central positioning of the major topics in the 5W template provide the horizontal perspective, and makes the viewer think about the relationships between topics. How does the project methodology impact the requirements delivery? Do the requirements match the business case? Do the requirements reflect all locations and stakeholders?
Easy to recall. Mind maps create a visual representation of your project, and the picture really can be worth a thousand words. Visuals are easier for memory retention than pages of words.
Enable change. Today’s software development environment is short and agile. The BA operates in an environment driven by change, disruption and transformation. The 5W mind map enables free thinking within defined boundaries, and also provides an impact map to assess shifts and changes.

SUMMARY

The 5W mind map is a useful tool for requirements planning and management. The starting topics of Who, What, Where, When, Why and How provide a check list when collecting requirements and a reference during the life of the project.

The attached file presents an example of a 5W mind map for a hypothetical project to provide digital signage at local swimming pools.

5 Common Business Analyst Pitfalls

Written by Brad Egeland on October 4, 2019. Posted in Articles.

What if you never dropped the ball as a team or project leader?

What if you could have every base covered? Wouldn’t that be amazing? You have all the information you need to make great decisions. All information and status updates you need to have the best and most accurate status reports and the most interesting and productive meetings possible?

Even though this seems to sound like it is focused on project managers, it is not. I am going to direct this at business analysts. One – because it’s my article and I often handle both roles and can do what I want AND Two – because business analysts in certain projects actually perform the more communicative and facilitator role than the more figurehead project manager. It depends on the project. But there are always those pitfalls. Those behaviors that can be detrimental to the project and we may not even know we are doing things wrong. Consider these five and then let me know what you think…

Micro managing resources.

Micromanaging is a huge mistake! You probably know that already and may just not realize you’re doing it. It serves no good purpose. Stop the oppressive behavior in your leadership style. You won’t be a respected and followed leader of projects and teams if the behavior continues. Your team members are in place because they are experts at what they do. Trust them until they have done something to break that trust. Expect the best and you’ll probably get the best. Help – don’t hinder – team progress, forward thinking, and innovation.

Canceling meetings.

I realize that sometimes it seems like the project is moving slowly and there is no need for that weekly team meeting or formal weekly status call with the customer. Plus, your desk is piled high with work on other hot projects and others on the project are probably in the same situation. So you’ll just do everyone a favor and cancel today’s regularly scheduled team or customer call on the slow project. Stop. This is not a good behavior. Why? Once you start to cancel meetings during slow times your stakeholders who have lots to do will start to consider your meetings to be of less importance and they won’t make your meetings a priority to attend in the future. You’ll be seen as an unreliable meeting facilitator. Even if you’re project is at a standstill, you should still proceed with the regular meeting. Even if all you do is give a quick status update and go around the room once to get any information about tasks that you can from each team member or stakeholder, it’s worth it. You’ve kept your meeting schedule intact. You also may have uncovered a small piece of important information from someone on the team that seemed inconsequential but could have been a big problem if it just fell through the cracks due to a cancelled meeting. You never know when the small things will become the big things. Don’t cancel meetings. Keep in touch, keep the communication flowing and the collaboration in place and the team cohesion strong. You will never regret it.

Multitasking.

If I can do one thing great, then I can juggle two things at once pretty good and three things at once fairly well and four things at once sort of acceptably ok… You get the picture? At that point you’re only performing ok in your own mind. Others may be seeing you as a bumbling fool. Give it up! It’s not worth it. I’ve previously covered my methods of managing projects (if you manage than one at a time) in 60 minutes a day. Try it – you’ll be amazed at how much more you’ll excel and how much more you’ll accomplish. If you’re leading, say, 5-6 projects at once, take a very dedicated 60 minutes on each project and get things done on each project – then move on to the next once. You’ll be amazed at how clearer your head will be, how much more you will accomplish and you won’t feel like you just bounced around all day between projects like a rubber ball.

Not following up.

Communication is Job One for all project leaders…. business analysts, project managers, tech leads, etc. and a huge factor in project success or failure. And a big part of that communication is follow-up. After a key meeting or phone call, be sure to follow-up with notes to ensure everyone is still on the same page. Gaps can grow over time. Don’t leave any gaps or room for misunderstandings or mid-communications. They can eventually kill a project.

Keeping senior management at arm’s length.

While you may think it’s nice to not have senior management meddling in your project all the time, having them somewhat involved and up to date is a good thing. Need a new resource fast? Go to senior management and get one. If they know more about your project than others than they will be more likely to take a personal interest and get your request expedited. Need more funding or their presence in front of the customer to help resolve an issue. Same thing – they will understand the project, remember you and jump in more quickly and provide that necessary involvement. Keep them in the loop – and continue to send them regular status updates.

Summary / call for input

The bottom line is we all fall short. We all need help. We all go through repetitious behaviors and we don’t always realize that they aren’t working. We might even be working contrary to or project’s best interests, or team’s best interests and our customer’s best interest. It’s not too late to change how we do things. These may not pop up during a lessons learned session so if you’re continuing with any of these practices or pitfalls… then you’re welcome for the heads up. Stop now!

The Disruptive Business Analyst

Written by Brad Egeland on July 24, 2019. Posted in Articles. 1 Comment on The Disruptive Business Analyst

Disrupt. By definition disrupt means “to prevent something, especially a system, process, or event, from continuing as usual or as expected.

To throw into confusion, throw into disorder, throw into disarray, cause confusion/turmoil in, play havoc with.”

From a technology perspective, it refers to “any enhanced or completely new technology that replaces and disrupts an existing technology, rendering it obsolete. It is designed to succeed similar technology that is already in use. Disruptive technology applies to hardware, software, networks and combined technologies.”

So, what about the disruptive business analyst? I work mostly with tech projects so for me the disruptive business analyst is working with what we used to call bleeding edge technology on new projects for anxiously awaiting project clients leading tech teams on exciting and sometimes dangerous new project adventures. End users and subject matter experts are awaiting a nearly ready solution during user acceptance testing (UAT) and at implementation rollout to the end user community with this creative solution. Hopefully the tech team… and the business analyst… along with the project manager have provided a workable solution that meets their requirements dead on. This can be difficult, of course, anytime you’re moving to a new technology that you’ve not worked with before, the project team hasn’t worked with before, the client has never likely seen or used it before, and that may not have been implemented in the client’s type of industry before. You’re on the edge… you’re going where no one has gone before (well, with that customer in that industry anyway…).

Stay abreast of new technologies

Since the business analyst is usually at least the liaison between the tech team and the project manager on a technical project – and is sometimes even the co-lead or sole lead of the project – then it is obviously critical that he remain relevant and current of ongoing tech trends and new technology. Through regular training, reading and research, this is easy to do and in terms of products, technology and security, conferences and the exhibit rooms at these conferences are a great way to get first hand face to face knowledge and deep dive information from the individuals creating and introducing this technology. Conferences like CES (Consumer Electronics Show), Interop and Black Hat will have briefings, demonstrations and training available for attendees and they can be fascinating ways to enhance your knowledge level.

Ensure the right team assembled for the tech implementation

A new technology is being used on our high-tech solution for the project client. Is our project team up for the challenge? Is the learning curve reasonable or do we need part time or full-time consulting or new resources on the project? That initial assessment must be made or at least assisted by the business analyst. And this determination needs to be made – and not lightly – as close to the kickoff of a new project as possible so as not to result in a timeframe extension, budget overrun and big, long learning curve for newly on boarded project resources.

Oversee customer training and education on the tech solution and the technology used

The project manager works closely with the customer throughout the engagement. There is no question about that. But on many tech projects the business analyst works even closer and for extended periods of time. On one of my projects, the customer wanted a change order to have the business analyst work full time onsite for the remainder of the project resulting in a $100k+ change order with a high profit margin added to the project. I was happy to oblige, of course. Especially in cases like this one, the business analyst is going to have the best feel for the customer’s ability to understand and eventually take over a new high-tech solution. Should education and training take place? Often the answer is yes. Yet another change order revenue opportunity! Win-win. This is an area where the business analyst will usually need to play point on – be aware.

Ensure Cybersecurity measures are taken

While hackers know that organizations using legacy technology are the easiest target, most get more challenge and enjoyment from cracking new technology. If you are embarking on new tech adventures on your project, know that you may be a target, especially if you are handling any sensitive data with this new tech angle. So, know that if you’re utilizing bleeding edge technology, you are on the hackers’ radar – you are a likely target will need to take proper measures. It’s best to address this possibility early in the planning phases while assessing risks and the skill set needed for your project team.

Summary / call for input

Are you a disruptive business analyst? Most business analysts working with startups and large corporations entering new areas of delivery are going to be utilizing new and cutting-edge technology. The key is to be fully engaged, ensure the client understands – at least to some degree – the new technology and that you have the right talent designing and implementing the project solution. Oh, and that the end user community knows what they are getting. It never hurts to make sure that your project manager is on board with the same technical understanding. Project management is sometimes project management across all complexities and industries… but I’ve always felt that a technical background is critical to the tech project manager’s success in managing tech projects. Sounds logical – and it is logical. I’ve seen it with my own eyes. I’ve got the tech background myself, but I’ve seen many colleagues fail miserably on technical projects because of a lack of tech background and understanding.

Readers – what’s your take on this list and these areas of emphasis? What would you add to it or change about? Do you agree with it? Tell us about a project you played a key role on using new technology and how you managed issues and risks – if there were any – in the implementation. Was it smooth? A success? A failure? Let’s share and discuss.

Business Analyst = Cybersecurity Expert

Written by Brad Egeland on June 27, 2019. Posted in Articles.

Ok, this may be a stretch to say “cybersecurity expert”, but I got your attention, didn’t I?

To me – and on all the “real world” tech projects I’ve managed – the business analyst has played the role of part-time tech and full-time tech liaison with the technical team on the project. They run the requirements definition portion of the project, they document – with project manager assistance – the functional requirements for the project and help extract the project client’s current business processes that are or will be affected by the project as well as helping to analyze and define what the new processes need to look like as we build the solution that will satisfy the business needs of the project client.

Easy process? No. Lots of work involved? Yes. Lots of documentation involved as well and much of it will become the basis for the full, detailed requirements document as well as what the ultimate solution is tested against as we run through user acceptance testing (UAT) with the project client. Defining all of this is critical to selecting the right technology, fully and correctly defining what the real requirements are, fully understanding what the “as-is” and “to-be” business and technical processes are or planned to be and fully preparing for the rest of the project.

Now, that said, the project manager has his role. The tech lead and team have their roles. Often, everything else might fall to the business analyst. And as we manage projects in ever increasing dangerous waters filled with hackers and data breaches, the business analyst may be taking on a new role in the smaller and/or less prepared project execution organizations. That is the role of the cybersecurity “expert.”

I’ve often said two things: data security and hacking are such a growing concern that no project should be consider “safe.” Hackers are always one step ahead of us and if you were on their radar you would have already been affected. But you may get lucky for a while. Sooner or later you will be affected to some small or potentially large degree. You can’t necessarily completely avoid or mitigate the hacker / data breach risk. But you can take measures. Does every project need some involvement from security as a part of the project team – if only as a sit-in during risk identification? I think so. Will all organizations eventually have a team of cybersecurity experts? Probably. But for now, that cybersecurity team or presence may just be one untrained or “in training” individual who has a strong interest in cybersecurity (or is forced to have that interest). And who is that likely candidate? The business analyst. In fact, the smart organization would be bringing in cybersecurity trainers right now to start getting the ground work laid for a solid team of security individuals tasked with keeping organization and customer data and systems safe from harm. The larger organizations should be putting a CSO (chief security officer) in place to guide the security infrastructure down the right path and career growths for those hired to be part of that infrastructure.

So, does the business analyst really = cybersecurity expert? In some cases, yes. And in the case where there is no real security awareness, representation or position on the project and in the organization the answer – in my opinion – is a definite yes. Get those BA’s in the organization as a whole at least educated on cybersecurity at a high level so they can begin to integrate cybersecurity awareness on the projects, the project teams and with the company’s senior management. It will give your project clients a better comfort level of satisfaction and confidence and hopefully provide some useful mitigation planning. There are some cybersecurity 101-type documents, videos, webinars and classes out there – often for free. Yes, that is all better than nothing. It’s what I’m immersing myself in – you learn something new and helpful with every watch or read. And I’ve attended many Las Vegas versions of the Black Hat digital security conferences over the years. They aren’t cheap, but they are if you get in for free with a media pass as I do because I’m also an author of these articles, white papers, eBooks and videos.

To get to the point of the proper cybersecurity presence, you can do one or more of the following 4′ things…

If you are a project-centric professional services organization – start with your business analyst or tech leads. In my opinion, this is probably the best way to start spreading the cybersecurity expertise to those who are most entrenched daily in the projects underway, about to happen, being planned and the customers they are working with. And it ensures that every project has a cybersecurity / cyber risk planning and management presence. That is priceless. And you have homegrown talent – also priceless.

Hire an outside consultant to review processes, projects and infrastructure and make recommendations. Expensive, but it can be a good start to building your own cybersecurity infrastructure. The expert will tell you what your needs likely are and help you plan a path to getting there including any re-organization and hiring you need to do today, a month from now and a year from now to be successful and safe. Expensive, but it will help the organization determine their real needs and how to get to the point of fulfilling those needs properly.

Hire cybersecurity talent and build a staff. If you are large organization handling sensitive internal or customer data, then you probably should have done this yesterday. So do it tomorrow and don’t procrastinate. And put a C-level security person in the organization – a CSO.

Hire an outside consulting organization to take part in necessary projects. Not your best choice for the money, but this can be a stop-gap measure if you find yourself suddenly immersed in projects that are highly data sensitive. As you move in that direction, the last thing you want is project failure and a big, highly visible data breach. So, if you must, then do this. It is far better than the alternative. And should something bad happen, it is far less expensive than the hack exposure.

Summary

Now is the time for action. Not tomorrow, not next year. Procrastination can cost millions in this instance. Train, buy, hire, or whatever… do something to protect your projects, customers and data.