Tag: Project Management

Careful now – can’t give any names, or particulars -since the following can’t possibly be a true story, I present it as humor, which it might be J.  Names and details have been changed to protect the innocent – if you recognize yourself, it must not be you. You wouldn’t do this. No one would!

Just before last Christmas, BA 007 got a call from a body shop called “Carrion Solutions, LLC”), based in North Kakalaki.  They really liked his resume, and the 20-minute phone interview that day, and wanted him to interview with their client (which we will call “Vermin International, Inc.”) immediately.

Sanity prevailed (for the moment), and the interview was postponed until January 4^th, with the caveat that the job might start shortly afterward.  The interview took place on January 4th, was grueling, yet satisfying. Vermin agreed with a best practices approach involving prototyping and use case modeling with as-is and to-be context diagramming, along with iterated validation with stakeholders and IT.

The Earth, it seemed, was round, at least on this project team.  After working with many Flat-Earthers these last few years, 007 was looking at a chance for a quantum of BA bliss!

As it happened, the job started two days later, with a bang. It turned out that 30 Minions had done a report on Vermin’s client, The Better Man’s Beneficent AdmonishNation.  As usual, the report was far from flattering, and the heat was on for quality requirements for rapid implementation – lot’s of money, lot’s of management attention, rapid decision making, plenty of stakeholder involvement. Goodness!

The project kickoff meeting at the BBBA was a hit. The client approved the best practice approach.  Sensing urgency, 007 had an as-is diagram ready the same week, ready for review and initial validation with the client (BBBA).

Vermin management refused to allow the diagram to be reviewed with BBBA, without explanation (remember, 007 works for Carrion, which contracts with Vermin, which contracts with BBBA).  During subsequent attempts by 007 to share and discuss the as-is with Vermin and/or BBBA, Vermin repeatedly cancels the meeting, simply doesn’t show up at the meeting, or uses the entire meeting to present other topics.

Now BBBA wants the diagram (Duh, you think?), and after a couple of weeks, Vermin agrees to let them have it, but no validation meeting is allowed. (There were two meetings allowed with 007, both of which the BBBA liked, felt were extremely productive, and resulted in mucho validationo).

The above process was then repeated for several weeks with other best practices such as clarity of scope (Vermin’s response to any discussion of scope) use case modeling (completely ignored by Vermin), and Business Process TO BE (Vermin already had a solution based on BileNet?).

After two months of this, 007 was in a jam. His originally identified goal of specifying as many as 40 use cases was shot, with a new goal of specifying 10-15 of the most important/complex use cases, as revealed by the use case model, which Vermin still refused to allow to be reviewed or validated by BBBA.

At this point, 007 used a brilliant tactic – the daily scrum!  After a couple of weeks of “socializing” the increasing urgency of proceeding with the use cases, 007 shared with the team that the lack of regular validation sessions with BBBA had finally become a hindrance to completing the requirements by the deadline, and that assistance from Vermin, and time with BBBA, was needed to proceed.  The offer of use case review was especially timely because the GUI team was begging for some kind of requirements “taxonomy.” They had long lists of GUI requirements that were, of course, out of context, and would benefit from a use case “taxonomy”.

The response?   007 was told to “Shut Up”, and that his “Round Earth” theories couldn’t help their “Flat Earth” requirements.

So shut up he did, turned in his drawings of the solar system, and left the project, but he advises his gentle readers to keep an eye on 30 Minions, just in case.

Have fun, and be sure to let me have your comments.

Don’t forget to leave your comments below

During a presentation on the topic of the BA and PM roles recently, someone asked me a question about personality types. She asked if there were, generally speaking, certain personality traits for PMs vs. BAs. I asked the crowd what they thought. Here are some of the responses.

• Big-picture and details. A BA said that she thought BAs have a broader perspective. They are more “big-picture,” and PMs are more detailed, she asserted. I asked the PMs in the audience what they thought and they said, as we might suspect, that PMs were more big-picture and that BAs were more detailed.
• Intuitive/logical. Another BA suggested that BAs are more intuitive. Again, I asked the PMs what they thought and they thought PMs were.
• Introvert/extrovert. Another suggested that BAs are more extroverted while PMs are more introverted. The PMs disagreed. For those not familiar with these terms, In general extroverts tend to be energized by people and introverts by thought and imagination. Extroverts tend to like to socialize and introverts tend to like their own private space. Extroverts tend to make quick decisions and introverts usually need more “think” time. Extroverts tend to speak and then think and introverts vice versa.
• Thoughtful vs. action-oriented. Someone suggested that PMs are more action-oriented while BAs more thoughtful, for which there was more agreement than on any other point.

I believe that both BAs and PMs share all these traits and more. Both need to see the forest and trees, both need intuition and logic, both BAs and PMs need to act and to consider, and both need to interact with others and be alone. However, I think they use these traits at different points in the project and for different reasons.

Big Picture/Details

Both the BA and PM roles require us to both understand the big-picture and keep track of the details. As they progressively elaborate requirements from the highest-level business need to the detailed functional and non-functional requirements, as they trace requirements, as they elicit and model requirements, and as they ensure that the ultimate solution solves the business problem, BAs have to keep both the big-picture and the details in mind.

 A few ways in which PMs need the big-picture perspective include working with the sponsor on the Project Charter and project objectives, making presentations to senior management to justify funding requests, and ensuring that all the details of the project trace to the project objectives. As PMs detail the project management plan, including the baselines, the communications plan, the estimates and schedules, the resource plans, as well as when executing and monitoring  the plans, they need to keep track of a multitude of details.

Intuition and Logic

 If, indeed, intuition is “keen and quick insight” (dictionary.com) or “understanding without apparent effort” (Wikipedia), then we could argue that both BAs and PMs need it. If logic is “reason or sound judgment” (dictionary.com) or a “tool for distinguishing between true and false” (cited in Wikipedia), then both BAs and PMs need logic as well.

Back in the proverbial dark ages, I had a consultant tell me that I was “very logical, for a woman,” and I took that as the greatest of compliments. A few years later, when “female intuition” was still considered a negative attribute for serious women in business, I proudly noted how intuitive I was to my boss. I remember that he quickly retorted that I wasn’t intuitive, but rather that my experience gave me what appeared to be intuition about such things as what to recommend, estimates, people’s behaviors and motives, etc. I agree that the more experience we have, the more easily we can navigate uncharted territories. However, I have found that some of us need less data for our decisions, and some more. I’m not sure, though, which role uses more intuition and which more logic.

Introvert/Extrovert

I would be hard-pressed to categorize either PMs or BAs as either type. There are times on a project when we need to interact intensely with others and times when we need our alone time. For the BA, each of the BABOK® Guide 2.0 knowledge areas has tasks and techniques that favor one or the other, but both are needed to complete all tasks. For example in Elicitation, the task to conduct elicitation activities requires more extroversion, while documenting the results requires more introversion. In the PMBOK® Guide developing the team requires more extroversion and creating the various management plans requires more introversion. In an online article in Forbes on November 30, 2009, Jennifer B. Kahnweller convincingly argues that introverts make the best leaders (http://www.forbes.com/2009/11/30/introverts-good-leaders-leadership-managing-personality.html ). Perhaps the most effective project professionals are “ambiverts,” hovering close to the center on a continuum from introversion to extroversion.

Thoughtful/Action-Oriented

 Although there are times on a project when we need to act and times when we need to listen and to step back and consider alternatives, generally speaking the BA is more thoughtful and the PM more action-oriented. The PM is more focused on delivery of the end product on time and within budget, so there is more of a tendency to act and act quickly. In general, BAs need to ensure that the end product actually works the way stakeholders want it to work, so there is more need to analyze alternatives and impacts and ensure stakeholders come to consensus on the requirements, which will take more time, consideration, and patience.

Enough for now! I want to explore this topic of personality traits for PMs and BAs more extensively in future blogs.

Don’t forget to leave your comments below

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:

1. 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!
2. 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:

1. A final draft, quality reviewed with the document authors and workstream leads
2. A structured document walkthrough with BA and TA leads and nominated SMEs and managers
3. 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].