Author: Richard Larson

Lessons Learned from Bhutan and Nepal: Part 1 – Product Thoughts

Written by Richard Larson on May 13, 2019. Posted in Articles. 6 Comments on Lessons Learned from Bhutan and Nepal: Part 1 – Product Thoughts

The two of us recently completed a fun trip with a small group to Bhutan after visiting Nepal on our own.

The country is amazing and everything we had hoped for. Bhutan is a mainly Buddhist country and their philosophy and approach to life permeated so much of our trip. It gave us inspiration to share a few lessons we learned along the way and try to relate them to product and process work.

A shortcut is not always faster.

One of the most famous sites in Bhutan (if not the world) is the Tiger’s Nest Monastery. Reaching it requires a steep climb of 3000 feet, which was daunting in part because of the altitude. Our group had 8 people in it and our guide was behind us helping one woman arrange for a horse to ride partway up (slacker!). Given our guide wasn’t present, 3 of us in the lead hit a crossroad. Not knowing which way to go, we followed a group of hikers in front of us as they took a route to the right and up. The opposite way to the left seemed to lead away from our destination so we went right. A hiker in the group ahead said it was a shortcut – and by that point we were tired enough that a shortcut sounded wonderful!

Well, we found out later that the shortcut was also steeper! And more tiring! Some of the slower hikers behind us went the “long” way and got to the meeting point much faster and were less tired. The longer way was flatter with a more gradual climb and easier footing.

So, the moral of this point is that when we are tempted to take shortcuts, be sure to get enough facts or data to help you make an intelligent choice. How many times on projects have we taken or been tempted to take shortcuts? They often result in rework and missed requirements. We can miss a crucial business need or overlook someone’s expectation by the need to move quickly. Organization pressures to develop solutions quickly tempt us into shortcuts, but the point is that we need to be mindful when deciding to take them.

Advertisement
[widget id=”custom_html-68″]

Some, but not all change is good.

Although Bhutanese people like to maintain their culture and keep it intact far more than other countries we’ve been to, they also embrace modern technology. For example, they don’t allow western franchises like McDonalds or KFC. But they have eagerly taken advantage of wi-fi and cellular technology. Monks in centuries-old monasteries use cell phones and laptops but they didn’t walk around with Starbuck’s cups. In other words, they have embraced some change, but rejected other changes that run counter to their cultural norms.

For product management, it is a good reminder that not all change is equal. We all know that product features need to be prioritized. But, how often do people have difficulty prioritizing them? (Answer: often!) This lesson is not a magic answer for how to prioritize. Instead, perhaps in the spirit of Bhutanese Buddhists, we need to ask: “Are we fulfilling the organization’s strategy with this feature or that requirement?” “Are we any worse off if we don’t make this particular change?” “What will the future be like if we add this function? If we do not add it?”

If these questions sound a bit like traceability, they should. We need to be asking these types of questions no matter what type of product or project approach in place. Instead of asking “how important is this new feature?” Maybe we should be asking “how might we benefit without it?”

No Hurry No Worry.

We all know errors happen when we rush things, but that’s not what we are referring to here. The roads in Bhutan were filled not with billboards but cogent sayings like “No Hurry No Worry” which appealed greatly to our group. It was a pleasant reminder that hurrying through a task or sprint or project is not helpful but can lead to errors and rework. That doesn’t mean we should tarry either. Instead it might mean rather than hurrying to build solutions, we should remember why we are doing the work we do. What is the higher purpose of it? What business objective or public policy does our work serve?

A “no hurry” approach might cause us to dig a little deeper to find the root causes of problems to help us generate better and more effective solutions. One of the authors personally objects to the concept of “satisficing,” which has made the rounds in Agile circles. Proponents of this notion believe that finding the first viable solution to a problem that “satisfies” and is “sufficient” will be good enough. We understand the appeal, but it doesn’t provide time enough to understand and to get to know the problem well enough to build lasting solutions. The satisficing approach may or may not get to the same end point eventually, but will usually take more time and expense of reworking solutions to get there.

In summary, our trip to a Buddhist country gave us many opportunities for refection. We wanted to share some and relate them to product and process work. (Check out our follow-up article inspired by Bhutan that focuses on process.) Here are some “mantras” for you to consider in your work:
1. Shortcuts can be long cuts.
2. Not all change is good.
3. “No Hurry No Worry”

Written by: Richard Larson and Elizabeth Larson

5 Trends in Business Analysis, Project Management, and Agile for 2019

Written by Richard Larson on January 7, 2019. Posted in Articles. 4 Comments on 5 Trends in Business Analysis, Project Management, and Agile for 2019

Since 2009 we have enjoyed reflecting on what’s happened the previous year and making predictions for the upcoming year.

Here are some of the recent trends we have discussed:

The digital BA
Lean business cases
BAs and PMs in a Dev Ops environment
Agile successes, challenges, and use beyond software
Strategic thinking as a key capability
Roles that help organizations maximize value
Scaling agile
BAs and PMs in the gig economy

Here are five industry trends that we have chosen for 2019

Digital Transformations

For the last few years “digital transformation” has been a buzzword which many BAs and PMs could relate to only in theory, if at all. Now many of us are working in or with organizations that are actually going through such a transformation. There are a myriad of difficult issues and pitfalls that can be avoided with some good advice and help. That’s where we BAs and PMs come in. As trusted advisors we can help organizations choose the right approach for transforming to the digital world. We can guide them so that they get maximum benefits from the use of digital technologies such as predictive analytics and AI.

As trusted advisors we can help organizations going through digital transformations understand the significant commitment needed to make such initiatives successful. Not only will there likely be organizational change upheavals, but the organization will need to consider new roles, like data scientists. They will need to obtain AI software tools and cleanse existing data. They will need to make important business decisions that reflect the ethics, culture, diversity, and values of the organization. These decisions will become the rules used in machine learning, and the wrong decisions can lead to a digital nightmare. Organizations are increasingly relying on BAs and PMs as trusted advisors to help business stakeholders understand the consequences of their decisions and provide a roadmap for achieving maximum value from their digital initiatives.

Increased Acceptance of Business Analysis on Agile Teams

The need for business analysts on Agile projects is not new. For several years we have noticed that more and more organizations have added an Agile business analysis (BA) role to the development team. What seems new, though, is the acceptance by the Agile community of the need for business analysis on Agile projects, regardless of the title or role assigned to that function. There is also more acceptance of business analysis tasks and techniques and a recognition that doing them provides value and better outcomes.

A comment by an Agile expert at a recent conference articulated this trend clearly when she noted that Agile deliverables often lack the usability and functionality needed by users when BA work is omitted or abbreviated. Teams are able to churn out releases quickly enough, but the outputs can fail to meet all requirements and have to be reworked until they do.

When teams focus on producing outputs and not enough on what the business needs, the results are no better with Agile than other approaches. Agile teams that embrace business analysis are realizing better and quicker value delivery whether it’s from initial needs discovery, effective requirements elicitation, complete requirements analysis – or all the above.

Related to this trend is a slight shifting away from using business analysts as surrogate product owners. We can only hope that trend grows, since a discrete business analysis role on Agile teams is an important advancement.

PMs Embracing Product-Centric versus Project-Centric Perspective

Many project managers who grew up professionally in a traditional project environment learned to see things through a project-centered lens. And why not? They are, after all, project managers. Many PMs learned to develop not only a sense of ownership but almost an identity with their projects which had a life of their own. One of the many ways Agile has changed our project worlds is the refocus from project to product. In fact, PMs may have heard, “No one cares about your project.” As difficult as that is for some to hear, PMs realize that to focus on the value proposition of the project means to focus on the product. PMs are becoming more comfortable with this perspective and incorporating the language of a product-centered view in even traditional project management environments. Project definitions of success have moved beyond “On time, within budget, and within scope,” and project managers are more product-centered when contributing to decision making. PMs realize that to be good stewards of project resources means focusing less on the project, per se, and thinking first about the what the project is delivering, why, and for whom. It’s about the value of the project deliverable and the customer…who really doesn’t care about your project. And that, gulp, is OK.

Advertisement
[widget id=”custom_html-68″]

Business Architecture on Agile Projects

In the early days of Agile, business architecture was often considered unnecessary overhead. Given that it seemed to take forever to develop a strategic business model, how could teams deliver value “early and often?” How could they “welcome changes?” Business architecture was thought to slow agile teams down since it meant long lead times before an Agile project could begin. Now organizations are realizing that business architecture has many benefits for Agile projects. It can aid in the budgeting process. It can help the team understand the interrelationship of business processes, particularly useful on complex projects with multiple Agile teams. And importantly, it can help ensure that a real business need exists before the team runs away with a solution that doesn’t solve any problem.

Business architecture is also being used to enable Agile teams to produce product features that fit together so that each one adds value. Organizations are embracing the idea that “Business architecture artifacts help the Agile teams prioritize, understand the business, and ensure their outputs provide ongoing business value. ” That’s because business architecture provides a model for avoiding non-value-added work. Sure, changes are good. Sure, rework and refactoring are welcomed in the Agile world. But imagine the benefit of delivering real value right away without any wheel-spinning. there is increasing utilization of business architecture to understand how each project and each feature helps meet business objectives and fits into the strategic direction of the company. So rather than being seen as unnecessary overhead, business architecture is being leveraged to do what it’s meant to do: delivervalue, not just features, early and often.

PMOs and COEs Combine To Address Enterprise Practices

More organizational PMOs (Project Management Office) and Centers of Excellence (focused on business analysis efforts) are combining into one functional unit (PMCoE) with the same manager supporting, developing, and implementing PM, BA, and Agile practices. This new unit typically establishes a repository of common tools and technologies needed to support these practices. It can also lead the hiring, training, career development, and day-to-day supervision of project professionals, whether PMs, BAs, or part of the Agile team. A PMCoE may also oversee all intellectual resources, the elicitation of stakeholder feedback, and any continuous improvement efforts. It can help ensure the alignment of all major change initiatives with organizational strategy and the promotion of strategic awareness of these key change initiatives.

PMCOEs can also help ensure that Agile best practices are understood and implemented consistently and appropriately at the enterprise level. They can check on the health of Agile initiatives, establish an Agile coaching function, establish metrics for Agile performance, and much more. Organizations are increasingly discovering the benefit of a combined PMCoE that improves organization efficiencies by pooling project knowledge and resources together In doing so they are fostering a culture focused on the improvement of projects, education, professional development, shared learnings, and strategic alignment.

References
Business Architecture and Agile Methodologies, Business Architecture Guild, January 2015

About the Authors

Elizabeth Larson is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. She has been a speaker for national and international conferences on five continents. She is a frequent contributor to Modern Analyst, BA Times/Project Times, Watermark Learning’s blog, and other outlets. She has been a lead author/expert reviewer on the several editions of the BABOK, the PMBOK, as well as PMI’s Business Analysis for Practitioners: A Practice Guide, and PMI’s Standard in Business Analysis. She and her husband Richard Larson have co-authored five books on business analysis.

Andrea Brockmeier is the Director of Project Management for Watermark Learning. Andrea is an experienced trainer, facilitator, speaker, and project manager, with over 25 years of business experience. Andrea oversees certification and skills development curriculum in project management, business analysis, and leadership. She has been a speaker at IIBA® and PMI® conferences and is an active volunteer. She enjoys practicing what she teaches and has a steady stream of projects that she manages. Andrea is highly committed to partnering with her clients through projects, consulting, and training, and seeks to make every engagement enjoyable as well as valuable.

Richard Larson is the co-principal and founder of Watermark Learning and has over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars to over 10,000 participants on five different continents. Rich has written frequent articles for Modern Analyst, BA Times/Project Times, Watermark Learning’s blog, and other outlets. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, was a lead author for the Needs Assessment chapter of PMI’s Business Analysis for Practitioners: A Practice Guide, and was a contributing author for the PM Body of Knowledge. He and his wife Elizabeth Larson have co-authored five books on business analysis.

Dr. Susan Heidorn is the Director of Business Solutions for Watermark Learning in Minneapolis. Susan is an experienced consultant, facilitator, speaker, and trainer, with over 25 years of business experience. Susan directs programs in business analysis, business relationship management, and leadership, including developing and delivering courses and creating new products. She has been a speaker at a number of IIBA® and PMI® conferences as well as local and regional organizations, boards, and private clients. She is a lifelong learner whose passion it is to guide people into achieving excellence in their personal and professional lives and works on creating positive impacts to the organization.

Top 5 Reasons Organizations Should Support Certifications

Written by Richard Larson on April 25, 2016. Posted in Articles. 5 Comments on Top 5 Reasons Organizations Should Support Certifications

There will always be a debate about certifications and whether organizations should support them. Some feel they are an essential and growing part of professional life. Others feel a credential does not make practitioners a better business analyst, Agilist, or project manager. Both sides have a point, and the debate will continue.

What is undeniable, though, is what we see as the organizational benefits for supporting certifications and credentials. Support can include (in no certain order): providing time to study for a certification exam, paying for certification classes, hosting study groups and forums, and incorporating credentials into hiring and promotion practices. We’re sure there are even more.

Here are the top five reasons organizations should support certifications and the benefits to those that do:

1. Facilitates a common language and set of techniques.

An industry standard and credentialing process, like the PMP or CBAP, unites practitioners across organizations and countries. Take the PMP, for example. Prior to the PMBOK and its framework, most organizations managed projects according to their own methods or those from a proprietary vendor. The large push to get project managers certified with the PMP helped organizations use a common language for common processes and techniques that had previously different terminology. This leads to increased mutual understanding which, in turn, increases quality and reduces re-work. Recruiting is also improved, and managers can hire with more confidence when candidates use common concepts and terminology.

2. Provides an avenue for employees to show dedication to a profession.

More than one CIO has told us they value certifications for the dedication that employees show when pursuing and achieving one. We couldn’t agree more. Some people will take initiative on their own and be self-motivated to achieve one independently. They are valuable staff members (and in the minority). Most people need some encouragement and a path for getting a credential. However, we don’t advise the routine use of credentialing as a way to weed out employees who don’t achieve one, but that is a subject for another blog.

3. People learn a lot when studying for credentials.

Successful, credentialed participants are almost always more effective at work. The reason is the amount of learning that has to take place in order to pass an exam. Even those of us who have been on the job and who have had training related to our industry (business analysis, project management, Agile), come to realize what we don’t know. Using my experience as an example, I (Rich) thought I understood project management until I studied for my PMP. Hah! What a mistake! Doing my prep work of reading, attending a class, and doing practice exam questions woke me up to the reality of what I did not know. Many hours of study later, spread over several months, got me ready to pass the exam. My studying also gave me increased PM knowledge which I still use to this day when managing projects and programs.

It is well to add here that some certifications usually result in more learning than others. “Broad industry standard” type exams like the PMP, CBAP, and PMI-ACP require rigorous study because of their scope. Almost invariably those studying for these exams encounter many “aha” moments, paradigm shifts, and new understanding as they study and find gaps in their knowledge. Our research shows it takes 100 hours on average of study time to prepare for the CBAP, for instance.
Another type of credential requires less study. These exams are narrowly focused and usually relate to proprietary methodologies, like the CSM, IREB, PRINCE2, BRMP, and ITIL. These types of certifications rely on a training class focused on key concepts after which candidates take an exam, often at the end of class.

4. Demonstrates commitment to employees.

Leaders in most organizations would say they are committed to employees. Saying it is one thing, but demonstrating it is another. Pay is one way, but people would not work for you without it. Promotions? Same thing, but to a lesser extent. Choice projects? Not everyone can work on them.

Providing the professionals in our organizations with a path to a relevant credential is a practical and meaningful commitment. It is a demonstrable form that employees will appreciate and will contribute to their long-term loyalty. We know this from first-hand experience.

“If you look after your staff, they’ll look after your customers. It’s that simple.”
Sir Richard Branson

5. Better employee retention.

This last point may seem counter-intuitive if you fear that helping people gain a credential only helps them land a new job. Anecdotal evidence exists that if you don’t train people, and don’t support them in advancing their knowledge and skills, they will likely leave sooner¹. The quote from Henry Ford sums up this point.

What do you think? Are there other reasons that organizations should support (or not support) certification? Please weigh in with your comments.

^1. See Training Magazine, www.trainingmag.com/content/training-increases-employee-retention. April 2013.