Tag: Change Management

Inheriting Projects

Written by Tom McIntire on May 9, 2018. Posted in Articles. 1 Comment on Inheriting Projects

Working in a corporate environment we are often asked to drop tasks and projects that we are currently involved in, so that our efforts can be concentrated on other initiatives within the organization that needs our attention.

We often need to transition these tasks to other individuals in the same or similar role as our own.

“One of the hardest things for someone working in Business Analytics is letting go of a project they are working on or transferring it to another Business Analyst.”

You have already put in significant time, effort, and energy to bring the project and stakeholders together and now you are being asked to transition it to another person. The first thing that comes to mind is a younger version of myself that says “I don’t wanna share! This is my toy!”. I was an only child, so I didn’t have to share a lot when I was younger, but when I did it was an effort for my mother to get me to do so. Thank you, mom, for teaching me this important life lesson early on, so that it is easier for me to share as an adult.

“It is perfectly acceptable to share our work with others when we need assistance.”

I have been on both sides of the coin (giving and receiving). It can be strenuous for both parties for different reasons, but the analyst receiving the project from another will have to perform more work initially in order to be brought up to speed on the project. Many times, you may not even know which questions to ask or what information you need as you have not been associated with the project in any role.

“Working in the field of Business Analytics, one needs to remain flexible and open to change.”

I have devised the below checklist to assist with the transition process from one Business Analyst to another. The checklist is meant as a guide or a talking point when creating your very own Transition Checklist. The Business Analyst should be thinking about the potential answers to each of the items during the initial transition of the project. Each project is different and working in the Business Analysis field, we need to be committed to change. Therefore, each Transition Checklist may be different. The checklist below is created from the aspect of the analyst(s) receiving an active project, however, the analyst(s) transitioning the work to another should be proactive and communicate as many of the touch points listed below as applicable to the project.

Identify:

Verify the tasks, goals, deliverables, and roles in the phase(s) owned by your team
Identify what methodology is currently being used: Waterfall, Agile, Agile-Waterfall Hybrid
Identify the project goals and scope
Are the correct resources on the project or are there resources missing?
Determine if it is possible for the previous analyst to stay on the project as a mentor for a short time period
Conduct a meeting to introduce yourself to the new project team. Make sure to cover the following:
Review established expectations
Review established ground rules
Review key decisions made prior to your assignment
Review Stakeholder roles and responsibilities for accuracy
Inform group of what they can expect from you moving forward
What is the current communication style?
Is there a communication plan?
Where is the project documentation stored?

Analytical Services:

Meet with the current analyst on the project and complete a knowledge transfer
Walkthrough of the requirements and project scope
Review the current BA Plan and complete any updates needed
Obtain written approval of updates from key Stakeholders
What are the deliverables (completed and outstanding)?
Project milestones
Change Requests
Requirements
What is the current phase of the project?

Project Details:

Meet with the Project Manager to cover the project timeline
What are the key milestones that will need to be completed and the dates?
Record the impact/risk of the transition of Business Analysts on the project
What is the current health check of the project: At Risk, Poor, On Schedule, Ahead of Schedule
What are the dependencies or relationships with other projects?
How many Project Managers are currently assigned to the project?
How many Project Managers have been transitioned off of the project?

Solution Details:

What are the Known Production Problems that are to be resolved as part of the project?
What are the details of the Release Schedule?
Who are the Third Party Vendors involved in scope, requirements, testing, or implementation?
What are the defects associated with the project?
What are the identified constraints?

What has a greater impact on Digital Transformation: Enterprise Architecture or Business Architecture?

Written by Scott Comte on February 21, 2018. Posted in Articles.

Around this time 12 months ago Gartner predicted that half of EA Business Architecture initiatives in 2018 would focus on defining and enabling Digital Platform Strategies.

While there hasn’t been follow-up research to prove whether this prediction has come true, anecdotal evidence would suggest that the real situation is pretty close.

In the research Betsy Barton, Vice President and Distinguished Analyst at Gartner stated:

“The increasing focus of EA Practitioners and CIO’s on their business ecosystems will drive organizations further toward supporting and integrating business architecture. This is to ensure that investments support a business ecosystem strategy that involves customers, partners, organizations, and technology.”

The core output of a Digital Transformation, from an IT perspective, is the development of supporting digital business platforms. However, with the growth of cloud-based services success in this transformation process is less a technology challenge and more a Business Model challenge. Digital Transformation can provide an opportunity for organizations to do business in a totally different way. But the fundamentals of business in a digital and traditional world remain the same. To run a sustainable business, you need to deliver a product/ service to customers that meet their needs in an effective and efficient manner and ensure that you continue to evolve that product/ service so that it continues to meet customer needs into the future. And you need to make a profit doing it. So you need to have a Business Model that achieves this.

Enterprise Architecture is very good at defining, and bringing a semblance of order to, the complex ecosystems that make up a business, particularly from a technology perspective. However, business architecture is what brings it alive. This is what Gartner calls this business-outcome-driven Enterprise Architecture, which emphasizes the importance of understanding the business and how it executes on its value streams.

TOGAF practitioners will proport that Business Architecture is an inherent part of the Architecture Development Method (ADM), which is true. However, I would argue that Business Architecture should be the key driver of the ADM to deliver a successful Digital Platform Strategy, rather than focus on some of the more traditional governance elements of Enterprise Architecture.

The really interesting aspect of the Gartner research is that Ms. Burton advises that one of the keys to success for the implementation of successful digital platform strategies will be the ability of organizations to integrate with other businesses digital platforms. While this will be a significant technical challenge, the key to deriving real business value will be ensuring that the platform and integrations align with the organizations strategic intent and support its value streams. In this context, Enterprise Architects will not only need to understand the business drivers and outcomes required by their business but also the needs of their partners in the digital ecosystem.

This ability to support the innovation agenda that is driving Digital Platform Strategies has also seen the rise of a new Architecture skillset, design-driven architecture. Gartner advises that “design-driven architecture will allow organizations to understand their ecosystem and its actors, gaining insight into them and their behavior which will allow organizations to develop and evolve the services that they need and consequently deliver on their business objectives.” In effect, it will allow Architects to be more customer/ human centric in their designs to better meet the increasingly complex needs of customers/ stakeholders. The key skillet that will be leveraging is Design Thinking or Human Centric Design.

With millions of dollars being pumped into Digital Platform Strategies the pressure on Architects is significant. They need to be able to manage the need to innovate organizations Business and Operating Models, often within Agile Development environments, while ensuring the interoperability of these platforms with other players in the organization’s ecosystem. In addition, they need to delight their customers/ stakeholders and in the private sector deliver a profit! With the continued development of Cloud-Based Services, the challenge of delivering these objectives by developing successful Digital Platform Strategies will be less of a technology challenge and more a business challenge.

When I initially posed the question of which discipline, Business or Enterprise Architecture, has a greater impact on Digital Transformation it wasn’t to say that both weren’t important. However, if you look at the underlying value proposition of Digital Transformation, it’s about doing business better and more efficiently by leveraging technology. To fully realize this promise the business models and value streams that deliver these outcomes need to be defined and tested based on customer/ stakeholder needs (Design Thinking) before the development of the technology platform to support them. It is, for this reason, I believe that Business Architecture will have a greater impact on Digital Transformation initiatives than Enterprise Architecture!

Business Rules – A Case Study

Written by Sandra Sears on January 30, 2018. Posted in Articles. 1 Comment on Business Rules – A Case Study

What exactly is a business rule?

According to the International Institute of Business Analysis, “a business rule is a specific, practicable, testable directive that is under the control of the business and that serves as a criterion for guiding behavior, shaping judgments, or making decisions.”

Business rules have impact beyond the scope of any particular project and are applied across the organization. A specific rule may impact operational processes (as in a rule that describes the time period during which a request must be fulfilled), enterprise data (as in a rule that describes a calculation), roles (as in the requirement to establish a new audit function), and events (as in a rule that requires reporting to a government agency for transactions in excess of a certain dollar amount).

While business rules are defined as being under the control of the business, the need for a business rule is often triggered by an external entity, through laws and regulations, through the actions of competitors, and through the behavior of customers. In this regard, the urgency to implement a business rule may not be under the control of the business.

Mitigate risk by being proactive

We believe that the “business rule” risk (along with many other risks) is mitigated by infusing business analysis competency into the organization – a business analyst can help bring order to sometimes chaotic processes and can serve to help mitigate risk in enabling an organization to quickly assess and understand the impact of a proposed change.

One company’s story

One of our clients, a mid-size insurance company, realized the need to move from a plethora of policy administration systems to a single integrated system that would enable the company to move products to market in a more integrated and rapid fashion. Prior to even considering candidate solutions, the company embarked on an architecture modeling endeavor, using process analysis techniques to understand their current state, identify process gaps, and appreciate opportunities for process improvements. As part of this process, they captured and documented business rules inherent not only in their existing systems, but in processes and procedures across the organization.

This company found that the work that they had already completed began to pay immediate dividends, and was clearly enabling the company to mitigate a non-trivial portion of the risk associated with such a system migration.

Prior to and then in parallel with their vendor search, the company began to collect and document their business rules. Like most other companies, they found that business rules were hidden in policy documentation, subject matter experts’ heads, and in system code. The work to collect the business rules was painstaking, but the long-term benefits of this effort soon became apparent.
The company quickly eliminated several candidate vendors, as it was clear that the solutions would not meet with company’s needs or could not support each of the product types that the company offered. By mapping key business rules against these vendor solutions, it was evident to both the vendors and the company which solutions were not appropriate.
The response from the vendors whose products were candidate solutions was one of delight! Most vendor solutions today are highly configurable, and the ability to configure is based on a solid understanding of business process and associated business rules, so these vendors knew that their implementation pathway had been well paved with this analysis work.
Having developed a business rule capture and maintenance approach along with diagrammatic models that depict processes, data, events, and roles, the company will be able to quickly ascertain in the future what the impact of the development of a new product or the implementation of a rule change will mean, as the rules will be traceable to the products, processes, data, events, and roles that each impacts.

What were the benefits of using modeling and process analysis techniques over how the company had previously attacked product development?

Thinking about their business in a systematic way – its rules, its events, its roles, its calculations – made the process more focused. The team used business analysis facilitators both to elicit the required information and then to document it. The business analysts were also responsible for building the diagram representing the business architecture. Everyone agreed that having the diagram made the business processes and rules visible and, therefore, easier to discuss and change. It also provided a means for communication and collaboration among the team members.
Each product – its architecture and the rules it would use – was documented in a repository. If additional riders, benefits or components need to be added in the future, there would now be a single source for that information.
Performing business process analysis on all of the in-scope operational processes built a base of process flow maps and associated rules. These could be saved in a repository and, for any new development effort (including the anticipated development of new and innovative products), could be analyzed to identify areas of change.

It would be impossible to overemphasize the value of having the organization’s analysis assets in a repository. The requirements, workflows, rules, and overall process models were documented in an on-going, living data and requirements repository, available for use for the next development effort. In a way, these requirements will become the reusable code of the business and product development process and, as such, the product and rules architecture models. The process models and the requirements are tangible company assets, ready to jump-start future process improvement undertakings. Such models lay the foundation for a library and formed a solid basis for continuous optimization through a solid understanding of rules, requirements, and business process models.

All agreed that without the full-time commitment of strong, professional business analysts, none of these benefits would have been realized. As a result, the organization is in the process of building its own internal business analysis and rules expertise. Their desire is to continue to reap the benefits of mitigating risk through a disciplined business rules and analysis approach.

Business Architecture in an Agile World – the What and the How.

Written by Scott Comte on January 11, 2018. Posted in Articles. 1 Comment on Business Architecture in an Agile World – the What and the How.

My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.”

This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!

Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.

The principles of Agile are very straightforward. Agile methodologies focus on the following:

Individuals and Interactions rather than processes and tools
Working Solutions rather than comprehensive documentation and project plans
Customer collaboration rather than contract negotiation; and
Responding to change rather than following a plan.

For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.

For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.

I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.

Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.
Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.

So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.
In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.

This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.

I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.

The 3 Hygiene factors of the Agile Business Analysis

Written by Adam Davies on November 29, 2017. Posted in Articles. 1 Comment on The 3 Hygiene factors of the Agile Business Analysis

In this article we are going to be hearing from Fred Herzberg, the Wachowski siblings, that other BOK from the Business Architecture Guild, and Ann Landers in an endeavor to identify the prerequisites of agile business analysis.

Recently my colleges and I were having an interesting conversation about how agile should and can change based on the type of product, project, organization or industry that it is being practiced for.

It sounded like we were making a list of motivating factors for agile in different types of situations and environments, so I asked: “what are universal hygiene factors for the agile business analyst?”

“What’s cleanliness and sanitization got to do with agile business analysis?” I hear you say. I’m glad you asked.

In 1959 Fred Herzberg provided his motivation-hygiene theory, or also known as two-factor theory. In this motivation body of work, Herzberg distinguishes between:

Motivators that give positive satisfaction, arising from intrinsic conditions of the job itself, such as recognition, achievement, or personal growth; and
Hygiene factors that do not give positive satisfaction or lead to higher motivation, though dissatisfaction results from their absence. The term “hygiene” is used in the sense that these are maintenance factors. These are extrinsic to the work itself, and include aspects such as company policies, supervisory practices, or wages/salary.

This motivation theory can be applied to individuals and groups of workers, and I think it can be applied to work approaches and systems. So instead of going through the factors that can help motivate or improve agile business analysis, I want to talk about what has to be present in an organization for it not to fail.

So here we go, the three hygiene factors of business analysis:

There is no Spoon

“Do not try and bend the spoon. That’s impossible. Instead… only try to realize the truth…There is no spoon… Then you’ll see, that it is not the spoon that bends, it is only yourself” (The Matrix 1999)

All good business improvement people are agile in mind, spirit, and action. Without the agility as an attribute of people and groups, agile methodologies and traditions (such as SCRUM) are just another set of processes and artifacts to be followed and produced. Remember agility (including business analysis agility) is the ability to predict, react and adapt, within a given environment to achieve a goal.

The first hygiene factor then is to create a business improvement environment, where people are encouraged to be predictive and adaptive; where managers and leaders share not only information but their power to make decisions, regardless of the project methodology being used.

Goals, Objectives, Strategy… oh my

“…in the absence of a well-defined link to strategic objectives, stakeholder value delivery, and related capabilities results in duplicate, poorly coordinated, and even conflicting initiatives” (BIZBOK Guide v5.5 p198)

If we don’t understand the nature of the enterprise, what our desired outcomes are, where we want to go, it’s unlikely that any results from any project are going to realize the desired ends of the enterprise, including agile projects.

As a rule of thumb, the members of an agile initiative should be able to give a good answer to the following question “what are the strategic objectives that we are contributing to that lead to this bunch of smart dedicated and well-paid humans to participate in this agile project?” If we don’t have a good answer to this question, at best we could get lucky, and at worst we are wasting resources and even risk losing value.

So the second hygiene factor is for enterprises to have a good awareness of themselves, with an unpacked and communicated strategy from executives to projects and operational staff.

Change is good for you! You’re so immature!

“Maturity is the art of living in peace with that which cannot be changed, the courage to change that which should be changed, no matter what it takes, and the wisdom to know the difference” Eppie Lederer (aka Ann Landers)”

We all know and have been told that change is inevitable and good for individuals and organizations. However just focusing the change or project model, such as Agile, does not address how organizations consume and eventually benefit from frequent and in some cases on-going change. Remember Agile teams, that you may love pushing out incremental value in your sprints, but there are some stakeholders who see it as a disruption to ‘real’ work.

The ‘change culture’ of an organization is more than just having the agility attribute in each individual who is a target for change, it’s the organization pulling together the people, processes, information and technology for change as well as ensuring we pursue the right change in the first place.

The third and final hygiene factor is ensuring a fit for purpose change environment and culture. If we can’t manage any change that’s fatal and a quick end to most enterprises. An organization that is engineered for continuous change, may mean a costly and undesirable situation for customers and shareholders.

So that’s it. I hope you got something new from my take on Agile. Remember the shiny aspects of Agile are not enough to motivate business improvement alone.