BAs Adding Value to Projects

Written by Ian Partridge on January 19, 2010. Posted in Articles.

I’m sure there must be a thesis somewhere on this question: How do you know whether a specific decision or action definitely influences the actual event? I like soccer analogies – in a pre-World Cup game against Argentina, Sven-Goran Eriksson then manager of the English national team, was praised for his tactical decision to bring on Peter Crouch and the 3-2 victory that resulted. Yet, Eriksson was slated for poor substitution decisions during the actual tournament when those decisions did not lead to a more positive outcome. In truth, can you really prove these decisions have either a positive or negative outcome? England may have beaten Argentina without the introduction of Crouch and, during the World Cup, the outcome of the games could have been even worse if the substitutions hadn’t been made!

I would like to think deliberate decisions and actions can influence a positive outcome, and I especially believe this is the case when business analysts work on projects and are able to play an effective role.

Too often I have experienced misunderstanding of what the business analyst role is and what it can add to a project. This article looks at how business analysis activity can have a massive impact on the outcome of a change program.

Context and Challenges

Following an earlier company acquisition, a leading telecommunication company initiated an IT project to decommission a legacy billing and customer care system and migrate to the company’s strategic systems.

Similar projects in the past had taken at least 18 months to complete, were poorly managed, and had run over time and budget. This particular project had been initiated twice before, had not progressed, and there was no documented output. However, expectations had been set by IT that the project would be completed in five months.

Contractual arrangements with the vendors of both legacy and target systems were driving accelerated delivery time scales, and a staff rationalization program was underway in the impacted business area in preparation for the new system.

No resources had been allocated to the project – apart from me, the lead business analyst.

I am a strong advocate of best practice; however, proven methodologies, training and technical skills very rarely provide a ready guide for dealing with challenges such as these!

Scope of the Project

The company’s project methodology was to undertake an initial feasibility phase or, what it was to be in this case, an unfeasibility phase! There was a view among senior management that the changes would impact about 5,000 customers and could be achieved by manually keying customer details from one system to another. In fact, the scoping activity completed as part of the analysis made clear that this was a business transformation project, migrating systems that were at the very heart of the acquired company, and involving very significant changes:

100,000 customers would be impacted, and nearly every interaction they had with the business would change: changes to bills and billing dates; the company brand they were familiar with; changes to the TV channels they received; and other services gained or lost
The opportunity to adopt a standard operating model – based on virtual contact centers, centers of excellence and consistent national processes.

Managing Expectations … or Trying To

At a meeting to discuss the way forward that involved senior stakeholders and the recently appointed project manager, I highlighted the issues regarding scope, risks regarding previous projects of this type, and the opportunities the project provided. Although the stakeholders took the issues on board, the time constraints remained, and it was agreed to undertake a five-week impact analysis.

It would be nice to recount that the business analysis view was readily accepted, but this wasn’t the case. Often, the task-focused, project management view of implementation conflicts with the business analysis objective of a quality implementation that delivers value and business benefit. This was the case here. Again, best practice would say that success factors would be agreed upon and defined at initiation, yet this had been ignored The first two bastions of project management – time and cost – were being pushed hard with little consideration being given to the third – quality!

With business analysis resources increased to three and a remit to engage technical staff, a framework was agreed upon to carry out a gap analysis between target and source systems. An aggressive schedule of workshops was planned, and senior managers across the business were consulted to ensure the project scope fully addressed the benefit opportunities and business goals. This also provided the chance to get commitment from areas supplying subject matter experts (SMEs) to the project, as well as re-setting expectations around required activity and timescales.

A key success for the gap analysis was fully engaging the SMEs attending workshops. The approach we took was to be clear about:

The drivers of the project
Why we were doing this work in a tight timescale
Why we needed their involvement

This simple, yet often overlooked, approach had immediate benefits: contact center staff were surprised at the high cost of extending the support of the legacy billing system. They thought the motive for the change was purely headcount reduction. Involving staff in the decision-making reduced resistance to change and led to more motivation and commitment.

The output of the gap analysis highlighted two things:

The impact of replacing these legacy systems was extremely broad and deep. More than 100 sub-systems and interfaces would need to be changed or decommissioned. No simple keying of customer details!
The work was estimated to take 10 months to complete.

Business Requirements and Detailed Analysis

I’m still surprised that in many organizations, and on many projects, the benefit of doing analysis and undertaking requirements is not better understood. I won’t go into the pros and cons of various techniques other than recommending that the activity needs to be:

Fit-for-purpose
Appropriate to the organization
Communicated, in terms of its value, to relevant stakeholders

The output of doing this work on a major project is, undoubtedly, documentation. There were two main concerns we had to counter: the perceived lack of value of the analysis, and that this was seen as the reason to extend the project timescale by five months. I have often seen that tight project timescales lead to under-analysis; business managers sometimes prefer “doing” to understanding the “what” and the “how.” I’m sure many people have experienced solutions to problems that weren’t properly understood, or delays due to extensive change requests. Moving to “doing” too quickly only creates a false sense of progress. With good analysis, you reap what you sow.

The concerns were addressed by briefing the main project stakeholders on what we were doing and why, covering all the detail that would underpin the project plan and providing visibility of the work to be carried out. We also highlighted how independent research supported the link between clearly understood requirements and success – especially for complex projects.

Documentation

We couldn’t avoid the fact that a reasonable amount of documentation would be produced due to the breadth of work. To make this as pragmatic as possible, a document template was defined from scratch to ensure that only the relevant information was captured, that it was easy to populate, and that it would be consistent and easy to read. The format was agreed upon by major stakeholders, ensuring expectations were managed and avoiding resistance to receiving documents.

As for the gap analysis, we were to engage many SMEs and would need to cover a fair degree of technical input. The work was divided into workstreams, each assigned a lead BA and a lead technical analyst (TA) with my role as an overarching lead. Excellent relationships were fostered between the BAs and TAs, helped by the co-dependence of our roles, to make the work a success.

Relationships

I have always believed the softer skills are a far greater asset to a business analyst than the more technical ones. Interpersonal skills make the difference when resolving issues, managing conflict, communicating, influencing, etc. Active relationship building proved really effective on this project. Just as engaging workshop attendees had encouraged participation, and two-way communication helped address resistance to change, good relationships with TAs helped gain more buy-in from SMEs. In the end, more than 100 SMEs contributed to this phase of the project. I have seen situations where BAs and TAs do not work well together and have even heard a TA accuse BAs of “sucking out what we know and then documenting it.” This is perhaps a little extreme, though there is some truth in it when you consider what BAs do in terms of facilitating understanding.

The lead TAs on the project were given joint responsibility on authorship of documents produced. This was not only to address the workload but also resulted in their feeling fully bought into the analysis work and championing the output. As well as being another benefit of having a clearly agreed and pragmatic template, this also really helped in achieving sign-off for the work.

Sign-Off

Whilst communicating the template and approach for documenting the analysis, I also defined and gained acceptance for a sign-off process from the managers who were acting as operational sponsors. They were the people who would be committing their resource to the project, would be receiving the change into their areas, and their approval would be the measure as to whether the analysis was fit for purpose and a success. Attitude to formal sign-off can vary greatly within organizations, even where this is part of the internal governance of project methodologies and frameworks. I really believe that without proper sign-off you don’t have commitment, true buy-in or a proper baseline to manage further change by.

Reviewing the sign-off process led to a better understanding of the issues faced by sponsors, principle of which was the appearance of large documents in their inboxes with no real clarity of what they were really being asked to sign off, little understanding of impacts and insufficient time to review. The answer was a clear schedule of when each output document would be completed. The schedule had been agreed to by the BAs and TAs to ensure it was realistic but challenging, with each document being completed in three stages:

A final draft, quality reviewed with the document authors and workstream leads
A structured document walkthrough with BA and TA leads and nominated SMEs and managers
A final issue for sign-off by the sponsors

This proved really effective for the following reasons:

Everyone was focused on delivering work to meet the timescales in the schedule. Involvement in planning this and agreeing to it achieved commitment from everyone.

The quality review sessions made sure work was a good standard, consistent across all the areas, and that there was acceptable coverage of analysis.
The structured walkthroughs ensured all feedback was captured together and facilitated challenge and understanding of different viewpoints. You knew everyone had read the document as you were going through it with them.
Sponsors signed off documents quickly as their direct reports were heavily involved in agreeing to them during the walkthrough sessions.

Summary

Following the approval of this phase, the project moved into development and implementation and went live over a weekend with no problems of any significance. Although it was a month late due to data migration issues, it was described as the most successful migration project undertaken by the company.

A review of lessons learned highlighted the appropriateness of the approach taken to analysis. The effectiveness of working relationships between BAs and TAs, clarity of scope, division of work across functional areas, and the actual documentation were credited as contributing to project success.

The company used the analysis approaches described above as the blueprint for a subsequent migration project that had been on the back-burner for a number of years, and without doubt, the experience of this project gave the company the confidence to undertake it.

Given the opportunity, business analysts can make a real difference to the projects they work on, and the success that follows is no accident.

Don’t forget to leave your comments below

Ian Partridge is an experienced BA manager and business change professional. Currently working as a contractor/BA consultant, Ian has more than 12 years of experience, including media, asset management, telecommunications, banking and retail. For more information visit www.2broconsulting.com . Ian can be reached at [email protected] and [email protected].