Charann Consulting

Star Base” The Value of a BA: Project Portfolio Management

Another area that many Cincinnati, Dayton and other organizations across the country and internationally miss is utilizing the Business Analyst (BA) role in Enterprise Analysis, in particularly in giving assistance in “Project Portfolio Management”.

The goal of the BA in this role is to ensure that the proper mix of projects get approved through the organizational project governance body that best helps the organization achieve its short-term and long-term strategic objectives.  In addition the BA should ensure that there are no conflicting requirements or objectives of the projects being approved.

I worked for an organization that had a formal IT Steering Committee that considered each and every enterprise application development project proposed.  This IT Steering Committee was made up of the business leadership from all business lines and regions of the business and the Senior IT manager responsible for application software development within the organization.  The members of this IT Steering Committee would then rank the projects that were before the committee to determine which projects would get approved; those receiving the lowest ranking would receive approval.  Many organizations may have similar processes, whether they actually take a vote or not; but this organization missed the point because there were no BAs involved in this process.  The projects were presented to the IT Steering Committee by the IT Manager.  The process would have achieved greater results if the Business Executive Sponsor presented the project to the IT Steering Committee as they are most passionate about the business need and that the project would benefit them.  The BA would sit in support of the project as they did the initial analysis that provided the business need and the solution idea for that business need.

However, in this role the Business Analyst, or Enterprise Analyst (EA), would work with the IT Steering Committee or governance body to ensure that the projects receiving approval are the optimal mix of projects and helps the organization best fulfill its strategic objectives.  This EA would present to the governing body the strategic alignment and conflicting issues of the set of projects before the governance body and make recommendations as to the projects that should receive approval based on those criteria.

With this additional information the governance body can make a more informed decision to ensure the portfolio of projects that receive approval are best aligned with the strategic objectives of the organization and reduce the conflicting interests, requirements, issues and scope between the project.  This will help ensure that the organization meets its strategic objectives from year to year.

I’ve rarely seen an EA in action. I blame this partly, again, on management having little understanding of the business analyst role. There are so many assumptions and judgements about the role that it is difficult to cut through all the layers to get to the heart of the work. It is the dinosaur way—management knows all. I also blame it partly on the unwillingness of people to ask the most basic question great business analysts ask—“why?” This sends most if not all running for the door to kick the BA out.

When organizations come around to understanding they need leaders not managers, then a collaborative approach to project management with everyone including business analysts in the mix questioning and pulling will start to come about.

LeslieJ.net: Push vs. Pull Requirements

Are BA’s conditioned to be in a “Push Requirements” mode or a “Pull Requirements” mode?

Sadly, I tend to think that many BAs just do the job they are told, take requirements at face value and operate in a “Push” mentality where stakeholders spout out directives for the solutions they want. Even worse, the BAs just write it down and “push” it along to the development team before turning their back and moving onto the next project.

“Pulling” requirements is a lot harder. You have to push for the ‘Why’ and understand the true need of the business. What problem are they trying to solve? Even more importantly, what problem can you solve that they don’t even realize they have?!? Figure out that, and you’re a super-star! The “pulling” can’t stop there though. Requirements are not one-sided. The IT stakeholders are equally as important.

So, here are three tips for operating in a “Pull Requirements” mode.

• Force Divergent Thinking: Pushing stakeholders, both business and IT, to look at the requirements from different angles and discuss options and variations then opens the door for a convergent conversation. While narrowing to a set of selected requirements and preferred solution you’ll uncover hidden priorities and objectives the stakeholders have and end with a more accurate set of requirements that meet the true business needs.

• Write Requirements from the Customer’s PoV: The system shall this, the system shall that doesn’t really mean much. Whether you’re in a waterfall or agile project methodology, try out User Stories. They convey the requirements from the customers point of view and force you to identify the benefit for developing the feature the customer is requesting.

• Create Requirements Visuals: Stakeholders rarely read lengthy requirements and you never want to create a situation where the way requirements are presented shut stakeholders down. When possible create visuals that represent the requirements. Its an ideal way to facilitate the conversation and collaboration needed in order to get to input and verification.

Happy “pulling.”

Being more cynical than I would normally like, poor business analysts are all about the push. In fact, these individuals are usually not business analysts at all but people who have adopted the “title” for nefarious reasons or the title has been foisted on to them by managers who don’t understand the career. Consultants usually fall into this, because they template out the requirements for one project and then are pressured to reuse them over and over again to cut down time and increase profits for the consulting company. I know - I’ve been on both sides of the equation and pull is always more rewarding on all fronts.

(Source: lesliej.net)

HBR: Why Appreciation Matters So Much

I’ve just returned from an offsite with our team at The Energy Project. As we concluded, I asked each person to take a few moments to say what he or she felt most proud of accomplishing over the past year.

After each of their brief recountings, I added some observations about what I appreciated in that person. Before long, others were chiming in. The positive energy was contagious, but it’s not something we can ever take for granted.

Whatever else each of us derives from our work, there may be nothing more precious than the feeling that we truly matter — that we contribute unique value to the whole, and that we’re recognized for it.

The single highest driver of engagement, according to a worldwide study conducted by Towers Watson, is whether or not workers feel their managers are genuinely interested in their wellbeing. Less than 40 percent of workers felt so engaged.

Feeling genuinely appreciated lifts people up. At the most basic level, it makes us feel safe, which is what frees us to do our best work. It’s also energizing. When our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value.

So why is it that openly praising or expressing appreciation to other people at work can so easily seem awkward, contrived, mawkish and even disingenuous?

The obvious answer is that we’re not fluent in the language of positive emotions in the workplace. We’re so unaccustomed to sharing them that we don’t feel comfortable doing so. Heartfelt appreciation is a muscle we’ve not spent much time building, or felt encouraged to build.

Oddly, we’re often more experienced at expressing negative emotions — reactively and defensively, and often without recognizing their corrosive impact on others until much later, if we do at all.

That’s unfortunate. The impact of negative emotions — and more specifically the feeling of being devalued — is incredibly toxic. As Daniel Goleman has written, “Threats to our standing in the eyes of others are almost as powerful as those to our very survival.”

In one well-known study, workers who felt unfairly criticized by a boss or felt they had a boss who didn’t listen to their concerns had a 30 percent higher rate of coronary disease than those who felt treated fairly and with care.

In the workplace itself, researcher Marcial Losada has found that among high-performing teams, the expression of positive feedback outweighs that of negative feedback by a ratio of 5.6 to 1. By contrast, low-performing teams have a ratio of .36 to 1.

So what are the practical steps you can take, especially as a manager, to use appreciation in the service of building a higher-performing (and more sustainable) team?

1. As the Hippocratic oath prescribes to physicians, “Above all else, do no harm.” Or perhaps more accurately, do less harm, since it’s unrealistic to do none. The costs of devaluing others are so great that we need to spend far more time thinking than we do now about how to hold people’s value, even in situations where they’ve fallen short and our goal is get them to change their behavior for the better.

2. Practice appreciation by starting with yourself. If you have difficulty openly appreciating others, it’s likely you also find it difficult to appreciate yourself. Take a few moments at the end of the day to ask yourself this simple question: “What can I rightly feel proud of today?” If you are committed to constant self-improvement, you can also ask yourself, “What could I do better tomorrow?” Both questions hold your value.

3. Make it a priority to notice what others are doing right. The more you work at it, the better you’ll get at it, and the more natural it will become for you. For example, start by thinking about what positive qualities, behaviors and contributions you currently take for granted among the members of your team. Then ask yourself, what is it that each of them uniquely brings to the table?

4. Be appreciative. The more specific you can be about what you value — and the more you notice what’s most meaningful to that person — the more positive your impact on that person is likely to be. A handwritten note makes a bigger impression than an email or a passing comment, but better any one of them than nothing at all.

We’re all more vulnerable and needy than we like to imagine. Authentically appreciating others will make you feel better about yourself, and it will also increase the likelihood they’ll invest more in their work, and in you. The human instinct for reciprocity runs deep.

(Source: linkedin.com)

Do you address the complaint, address the root cause, or both?

Imagine a future where robots run the hospitals as a way to cut health care costs.  A robot ambulance pulls up to the door of the Emergency Room with an unconscious patient.  The robot triage nurse connects electrodes to the patient and notices a low heart rate, low blood pressure, and intense pain readings emanating from the abdomen.  The diagnosis: blood loss and pain.  Prescription: provide blood and pain killers. 

Then, in comes a human physician who notices that the patient has a gunshot wound.  A surgery team swoops in and removes the bullet and patches the patient up.

OK… time to switch metaphors.  Your business is going along, operating normally.  A customer comes in the door with a complaint.  The product he purchased is broken within a few minutes of getting it. 

• Do you respond like a robot and give him a new product and a coupon for 10% his next order?
• Does the physician ever arrive to take a look and decide that the company is manufacturing low quality products?  Is anything ever done about the underlying problem?

Enterprise architecture has the same problem in more ways than one.

• If someone complains that the EA team is not providing value, do you respond like a robot and send your architects to jump onto a visible and important project and “be useful?”  Do you follow up to diagnose the root cause of the perception?  Do you deal with issues in governance, communication, information accuracy, process integration, and expertise?
• If you notice a complex area of the business is never actually getting cleaned up, and that complexity is causing business agility problems, do you create an initiative to simplify the complexity and then stop there, or do you follow up with a project to address the institutional decision making, roles and responsibilities, and design principles that led to complexity in the first place?

A word of advice: when a problem erupts: triage is important, but surgery may be necessary.   Don’t solve the underlying problem without dealing with the symptoms.  Don’t deal with the symptoms without also addressing the underlying problem. 

Indeed, a conundrum of what to deal with at first for individuals who preach process without actually thinking holistically.

(Source: blogs.msdn.com)