Tag: Planning

Project Manager and Business Analyst In Tandem for Success

Written by Sergey Korban on October 13, 2014. Posted in Articles. 1 Comment on Project Manager and Business Analyst In Tandem for Success

I’ve been working in project management and business analysis domains for many years. The projects I’ve been engaged in cover regulatory compliance, business process improvements, software development, ERP implementation and ITIL adherence, just to name a few.

Heated discussions about relationships between a project manager (PM) and a business analyst (BA) are often focused on their non-aligning sides rather than on their mutual efforts to ensure project success.

I tend to think about PMs and BAs working together in projects as two hands carrying a baby. Here is my view on the PM-BA tandem and how it comes together to make a project successful.

How It Works

I’ve been involved in multiple projects for the last two decades. The projects were of different scales and nature. However, there is one common element in all of them: a project manager and a business analyst are the two sides of the same coin. Their skills and joined efforts make a project successful and deliver good value to the business. I would like to demonstrate how a PM and a BA could work on a project, and explore each project phase in more detail. Please note that project phases and the documentation involved follow PRINCE2®.

Project Start Up

PM and BA work with project stakeholders throughout the entire project lifecycle. Before the project starts, a PM deals with business stakeholders to identify the business need at a high level. The outcome of this interaction is a Project Initiation document. This document outlines the business need, the impact of the current state on the business, the desired target state, project complexity, estimated project duration and expected benefits.

PM-BA: Collaboration Model

Project Initiation

The PM engages the BA to help with project scoping and definition of the business need, expected project outcome (deliverables) and project acceptance criteria.

While the PM works on drafting a project plan, the BA develops a BA plan outlining BA deliverables, communication patterns with stakeholders, requirements management approach and estimation of effort. The BA agrees the BA plan and Requirements Management plan with the PM.

Once the plans are agreed, the BA works closely with the project stakeholders on clarifying the business need, specifying high level business requirements, conducting stakeholder analysis, identifying risks, assumptions and constraints, as well as tolerances to a solution. The BA determines solution scope, high level requirements, solution approach, reusable and new components to be used in the final solution. The BA works closely with the PM to align solution scope with project scope. The BA informs the PM about all identified and potential risks.

The PM maintains the risk register and develops mitigation strategies for the identified risks.

The joined efforts result in two key documents: Project Vision and Solution Vision. The former contains the problem statement, desired outcome statement, acceptance criteria for deliverables, stakeholder analysis, business context, assumptions, constraints and scoping definitions (in scope/out of scope).

The latter describes the problem statement, solution statement, provides a solution overview, stakeholder summary (RASCI), determines “to be” capabilities and business context, defines what is in and what is out of solution scope.

These two documents support the Business Case document in medium and large projects, supporting project sponsor’s decision-making on whether to go ahead with the project.

The PM and BA work jointly on developing a WBS to ensure that the solution can be assembled in a way that enables cost efficiency and adherence to project time and resource constraints.

Project Execution

This phase flags even more close collaboration between PM and BA. They work together in requirements workshops to prioritise and validate requirements. They conduct workshops with vendors of components to the solution (where applicable).

Changes to solution scope lead to changes in project scope so the PM applies change management process to ensure that only justified changes will be accepted. The PM maintains the change request register throughout the project.

BA’s reporting on progress in turn supports the PM’s reporting on project progress to the project sponsor and other interested parties.

The PM supports the BA in communication with solution architects, software developers and other engaged third parties with regards to solution validation activities. The same is true when it comes to user acceptance testing. The PM’s support is invaluable here. The duo works hard to ensure that solution acceptance criteria will be met within the predefined tolerances. The BA facilitates solution implementation to ensure a smooth transition to the “business as usual” mode.

Project Closure

Having the project deliverables accepted by the business, the PM works on closing the project. The BA facilitates the project closure by providing feedback for the post-implementation review. The BA reports on how well the solution met the business requirements. They jointly work on the Lessons Learned log to ensure that all valuable information has been captured for further use in future projects.

The BA hands over artifacts such as business requirements, functional requirements, use cases, non-functional requirements and solution technical specification to the business. These artifacts form a basis for business documentation on how to use the solution.

When the project has been formally closed, the BA files all approved BA artifacts in a central repository.

Pain Point

From observing over the years how different PMs tackle their projects, I would like to highlight some things that can trigger a blaming attitude.

A bossy attitude to a BA, a lack of understanding of the business domain, skipping important project background where the rotation of PMs takes place, “managing” customer expectations without involving the BA, expectations of having the final solution requirements identified by the BA after a single requirements elicitation iteration with project stakeholders – all these elements create a foundation for blame for not delivering on time and under budget.

Conclusion

The complexity of modern projects has increased to a great degree. Changes to business processes are coupled with changes to business applications, IT infrastructure, and interfaces with the company’s environment. The PMs and BAs are required to be more productive in projects of different nature. My experience gained from over 35 projects confirms that to deal with the changing demands and make projects successful, the BA and PM should work in tandem pushing towards the finish line.

Shared responsibilities, mutual respect and support combined with collaborative attitude pave a way to project success.

Don’t forget to leave your comments below.

Back To The Future: Two Ways To Develop Better Future State Skills

Written by Bruce Harpham on September 29, 2014. Posted in Articles. 2 Comments on Back To The Future: Two Ways To Develop Better Future State Skills

A key business analyst skill is describing the future state of a project. After the dust settles, what does the customer get? What will the website do? Articulating answers to these open ended questions is a key ingredient to the project planning process.

Producing a future state document requires creativity and strong relationships with stakeholders. In this article, I will cover both of those areas. By implementing these ideas, you will be able to make a greater contribution to your projects.

Tip: For guidance on how the future state concept fits into business analyst deliverables, read Sergey Korban’s article here, The Structure of Business Analysis Documents.

Improving your ability to develop the future state is a skill that has value beyond any one project. It is a way of training yourself to see opportunities. Rather than simply stating “improve process X by 5%”, you will have the capacity to ask bigger questions. Does it make sense to keep the process in place? There’s no point in improving a process that fails to create value.

Work Out Your Creativity Muscles With These Exercises

“Creativity is a great motivator because it makes people interested in what they are doing. Creativity gives hope that there can be a worthwhile idea. Creativity gives the possibility of some sort of achievement to everyone.

Creativity makes life more fun and more interesting.” – Edward de Bono

When you start a project, the desired future state is often vague. In the early stages, the project vision and project charter may still be under development. That is where your creative approach adds significant value.

Here are six other ways to improve your creativity skills at work. Practice these ideas and you will soon become the most creative person on your projects.

Ask “Why” three times. Asking multiple times is important because many people provide unhelpful answers at first (e.g. “that’s the way I was trained.”)
Study products and services outside of your industry. Jim Collins and Jerry Porras write about Nordstrom’s legendary customer service in “Built to Last: Successful Habits of Visionary Companies.” Part of Nordstrom’s success is due to training all staff in customer service.
Industry provincialism – studying only what your immediate competitors do – is a sure-fire way to limit your creativity in coming up with new ideas.
Read “The Ten Faces of Innovation” by Jonathan Littman and Tom Kelley to learn about how industrial design IDEO approaches product development. In reading the book, I found “The Anthropologist” concept the most interesting.
What would the ultimate customer say about this project? When you work on projects, you may think of your customer as another employee of the firm. The ultimate end customer is the person outside the organization who hands over their money to buy products and services. Focusing on the customer is one way to cut through the complexity that plagues projects.
Forget Constraints For A Few Minutes.
Constraints – limited time and money – are an ever-present reality for business analysts. At times, “excessive realism” hurts more than it helps. What would your project achieve for customers if the CEO handed you a blank cheque? Aim to come up with at least ten ideas!
Pursue Creative Activity Outside of Work.
When you’re a driven professional, it is easy to fall into the trap of thinking about work constantly. For the sake of your own happiness, you owe it to yourself to periodically explore a creative activity.

If you work with Excel and PowerPoint all day, consider experimenting with painting, drawing or music. In addition to intrinsic benefits, these pursuits help me to relax. That way, I’m able to be refreshed when I return to the office.

Work On Your Interpersonal Skills To Build Better Relationships

“The most important thing in communication is hearing what isn’t said.” -Peter Drucker

As knowledge workers, we communicate for a living. As you work on building a future state or a project vision, it is common practice to seek input from stakeholders. A large project could seek comment from sales, marketing, customer service, legal and other units. Some stakeholders will enthusiastically share their views while others will be taciturn.

As business analysts, we need to tools to work effectively with people. In the early phases of a project, you have the opportunity to build effective relationships. The following five tools and resources will help you work better with your stakeholders.

1. Get Your DISC profile and learn how to use it.

I learned about the DISC ( ) behavioural profile from Manager Tools. This instrument is extremely helpful in understanding your communication behaviours.

2. Take The Dale Carnegie Course.

One of the longest running business skills courses in the world, the Dale Carnegie Course comes highly recommended by Mary Kay Ash, Warren Buffet and Zig Ziglar. The course takes place over a number of weeks and offers ample opportunities to practice communication skills and receive feedback.

3. Talk About The Elephant In The Room.

Some people get nervous when analysts and project managers start talking about projects and the future state. The project can be seen as criticism of the people who run the status quo.

Address this concern openly by focusing the conversation on the future. Resist the urge to get embroiled in fights over the past.

4. Go Slowly.

Relationships with stakeholders are built over time. If you are meeting someone for the first time, they may be wary of you and the change you represent. Fortunately, you can build trust over time by keeping your word and communicating frequently.

Tip: Don’t rely on one mode of communication alone. For example, if you tend to use email, add occasional phone calls to your stakeholders to improve the relationship.

5. Practice Active Listening Behaviors.

Did anybody ever teach you how to listen effectively? It is not a skill that is widely taught despite its importance. Practice the foundations of active listening – maintain eye contact, take notes and periodically confirm your understanding verbally – to signal you are paying attention.

Tip: A classic active listening technique involves saying: “I understand that the invoice process takes up half your day – did I get that right?”

Discussion question: What is your favourite way to build the future state and get your projects started?

Don’t forget to leave your comments below.

Tips for Working with Off-Shore Stakeholders

Written by Robin Schreier Hohman on September 29, 2014. Posted in Articles. 1 Comment on Tips for Working with Off-Shore Stakeholders

In this global economy, facilitated by the Internet, Business Analysts are asked more and more to work with stakeholders who are located all over the world. Several issues can be challenging, such as setting up meetings that are convenient for all attendees, working on deadline when stakeholders are several time zones away, and understanding people whose native language is different than yours.

Time/Attendance Barriers

Depending upon the team’s locations, workday hours can be problematic. While sometimes you will be able to wait a day to get a response to an e-mail or a document review request, occasionally you will have to work after-hours to accommodate a time zone difference.

Tight deadlines call for more creative measures. On a recent project, I worked with technical and QA teams in Manila, which is 14 hours ahead of New Jersey. Working with the QA team was particularly challenging when I was asked to be the test lead for User Acceptance Tests (UATs), and the turnaround for defects was three hours.
Since I was on-call 24×7 for the tests, I worked from home so I could sleep between defect calls. This enabled me to facilitate solutions within the short turnaround. If I hadn’t done that, there would have been a one-day delay between issues and solutions, and even easily fixed items would have been dragged out. Working this way enabled us to get the work done on time, and the project met the go-live deadline.

Language Barriers

The global workforce is often made up of people who speak English as a second language. Sometimes, the on-shore workforce also speaks English as a second language. If you’re a native English speaker, this could present some challenges to understanding each other. Even native English speakers sometimes have trouble understanding each other; for example, I have a hard time understanding Australian slang.

Most of your interaction with the offshore team will be on the phone, sometimes on conference calls. It’s hard enough to figure out who’s speaking and what people are saying on calls with a large group of attendees; it’s more difficult when there are language barriers.

There are several actions you can take to get around the problem. For example, if you’re chairing a requirements meeting, try to use visual aids where possible.

Make sure to send an agenda and accompanying documents out with the meeting invitation if at all possible.

Sending artifacts two minutes before the meeting ensures everyone will be reading them, not paying attention to you speaking.

Make it clear that you are open to answering questions during any presentations or while working the agenda. If people are hesitant about interrupting you, key information will be missed.

A good rule for getting the most out of a conference call, regardless of language, is to make sure you ask follow-up questions about anything you’re not completely sure of.

If there are language barriers, a gentle, “I’m sorry, I’m not sure I understood you, could you please repeat that,” goes a long way to resolving issues. Don’t be afraid to ask people to slow down, or to repeat what they said.
it’s effective to repeat back to someone what they said. That way you will both know if you are grasping the concepts and details, or if you (or the stakeholder) missed something.

There are applications that can facilitate conference calls, such as Cisco WebEx and Citrix GoToMeeting. They both offer HD video, and enable attendees to view each other’s computer screens, which allows you to give PowerPoint presentations without boring everyone to tears. You can also share other documents, questions, and strategies.

I also use WebEx for presenting and discussing applications that are partially built or in beta. It gives people on the phone a better idea of the functionality than documentation and screenshots can, and it also gives people real-time experience with the app. Nothing beats working with an app for understand the user interface and functionality.

After a conference call, it is particularly important to follow-up with a clarification e-mail to ensure no information was lost in translation. You should always send a follow-up e-mail with key points and dates anyway. Write simply, “This is what I understand from the meeting,” followed by a bulleted list. If you know you missed some answers, repeat the questions in the e-mail. Don’t assume or guess.

Also, when writing for a global audience, remember that English, like any language, is filled with slang and idiomatic expressions, words that means something different when put together than they do individually.
Just state the facts, and, as always, strive for the clearest language possible. For example, instead of saying, “we have a tight deadline so we’re going to jump in feet first,” say, “we have a tight deadline, so we’re going to have to learn quickly.” If you use idioms, you will spend time explaining what you mean, or people will simply gloss over the words and miss important ideas. Remember, business analysis is all about getting the right information from the right people. Your job is to facilitate that process.

Don’t forget to leave your comments below.

Specifying Requirements for Outsourced Projects

Written by Karl Wiegers on September 8, 2014. Posted in Articles. 1 Comment on Specifying Requirements for Outsourced Projects

Rather than building systems in house, many organizations outsource development to contract development companies. They might outsource the work to take advantage of skills they do not have available in-house, to augment their internal staff, or in an attempt to save money or time. The outsourced development supplier could be located physically nearby, on the other side of the world, or anywhere in between.

The role of a business analyst is even more important on these projects than on a co-located project. If the team members are all in one location, developers can walk down the hall to ask the BA a question or to demonstrate newly developed functionality. This close collaboration can’t happen in the same way with outsourced development. Compared to in-house development, outsourced—and particularly offshore—projects face requirements-related challenges such as the following:

It’s harder to get developer input on requirements and to pass along user feedback to developers.
A formal contractual definition of requirements is necessary, which can lead to contention if differences of interpretation are discovered late in the project
There might be a bigger gap between what the customers ultimately need and the product they get based on the initial requirements, because there are fewer opportunities to adjust the project’s direction along the way.
It can take longer to resolve requirements issues because of large time zone differences.
Communicating the requirements is more difficult because of language and cultural barriers.
Limited written requirements that might be adequate for in-house projects are insufficient for outsourced projects, because users and BAs are not readily available to answer developer questions, clarify ambiguities, and close gaps.

This article suggests some techniques for successful requirements development and management on outsourced projects.

Appropriate Requirements Precision

Outsourcing product development demands high-quality written requirements, because your direct interactions with the development team are likely to be minimal. As shown in Figure 1, you’ll be sending the supplier a request for proposal (RFP), a set of requirements, and product acceptance criteria. Both parties will engage in a review and will reach agreement, perhaps with negotiation and adjustments, before the supplier initiates development. The supplier will deliver the finished software product and supporting documentation.

Figure 1. Requirements are the cornerstone of an outsourced project.

With outsourcing, you won’t have the same opportunities for day-to-day clarifications, decision making, and changes that you enjoy when developers and customers work in close proximity. Particularly with offshore development, you should anticipate that the supplier will build exactly what you ask them to build. You will get no more and (hopefully!) no less, sometimes with no questions asked. The supplier likely won’t implement the implicit and assumed requirements you thought were too obvious to write down. Poorly defined and managed requirements are a common cause of outsourced project failure.

As with in-house development, visual requirements models augment functional and nonfunctional requirements for outsourced teams. Using visual models to supplement written specifications is even more valuable if you are working across cultures and native languages, because it gives developers something to check their interpretations against. However, be sure the developers can understand the models you send them and interpret them accurately.

Prototypes can also help clarify expectations for the supplier team. Similarly, the supplier can create prototypes to demonstrate to the acquirer their interpretation of the requirements and how they plan to respond to them. This is a way to create more customer-development interaction points to make course adjustments early in the project rather than late.

Watch out for the ambiguous terms found in Chapter 11 of Software Requirements, 3rd Edition that cause so much confusion. I once read a requirements specification intended for outsourcing that contained the word “support” in many places. The BA who wrote the requirements acknowledged that the contractor who was going to implement the software wouldn’t know just what “support” meant in each case. A glossary is valuable when dealing with people who don’t share the tacit knowledge held by those who are familiar with the acquiring company’s environment.

Acquirer-Supplier Interactions

Without real-time, face-to-face communication you need other mechanisms to stay on top of what the supplier is doing, so arrange formal touch points between the acquirer and the supplier. Plan time for multiple review cycles of the requirements. Use collaboration tools to facilitate peer reviews with participants in multiple locations. Incremental development permits early course corrections when a misunderstanding sends the supplier’s developers in the wrong direction. If the supplier raises questions, document them and integrate the answers into the requirements. Use an issue-tracking tool to which both supplier and acquirer teams have access.

Outsourced projects often involve teams with disparate company cultures and attitudes. Some suppliers are so eager to please that they agree to outcomes they cannot deliver. When an error is brought to their attention, they might strive to save face by not fully accepting responsibility for the problems. Some developers might hesitate to ask for help or clarification, or to say “I don’t understand.” Employ elicitation and facilitation techniques such as reading between the lines for what isn’t said and asking open-ended questions. Establish ground rules with all team members regarding how they should interact when they work together.

Developers whose first language is different than the language in which the requirements are written might not pick up nuances or fully appreciate the implications of certain statements. They might make user interface design choices that you wouldn’t expect. Things as diverse as date formats, systems of measurement, the symbolism of colors, and the order of people’s given and family names vary between countries. The requirements should avoid the use of colloquialisms, jargon, idioms, and references to pop culture that could be misconstrued.

Change Management

At the beginning of the project, establish a change control process that all participants can use. Using a common set of web-based tools for handling change requests and tracking open issues is essential. Identify the decision makers for proposed changes and the communication mechanisms you’ll use to keep the right people informed. The outsourced development contract should specify who will pay for various kinds of changes, such as newly requested functionality or corrections made in the original requirements, and the process for incorporating the changes into the product.

Acceptance Criteria

Define in advance how you’ll assess whether the contracted product is acceptable to you and your customers. How will you judge whether to make the final payment to the supplier? If the acceptance criteria are not fully satisfied, who’s responsible for making corrections, and who pays for those? Include acceptance criteria in the RFP so the supplier knows your expectations up front. Validate the requirements before you give them to the outsourced team, to help ensure that the delivered product will be on target.

Properly handled, outsourcing the development work can be an effective strategy to build your software system. An essential starting point for a successful outsourcing experience is a set of high-quality, complete, and explicitly clear requirements. If the requirements you provide to the supplier are incomplete or misunderstood, failure is probably at least as much your fault as theirs.

Don’t forget to leave your comments below.

About the Writers:

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recent award-winning book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Practicing Simplicity in Analysis

Written by Santosh Shaastry on September 8, 2014. Posted in Articles.

Have you ever realized that innovations aim for one or more of these – Faster, Better, Cheaper, Sleeker – all these and more, while trying to keep things SIMPLE.

Only a few years ago, if someone told us that huge market existed for tablets it would have sounded presumptuous if not impractical. Tablets have actually replaced desktops and laptops across the world – from Sales representatives to home makers, the user base for tablets is diverse. This is a phenomenon that is worthy of a research to understand how human beings “adapt” and “absorb” simpler designs all the time! Don’t we always wish everything is simple and easy to do? – paying bills, buying groceries, watching a movie, reaching out to a loved one across the world at the touch of a button etc.

Analysts work with business problems and are expected to SIMPLIFY the problem to define a practical solution! After all, why would business folks need “analysts” if the job defining solution is “that” simple? Being one myself, I began on a quest to understand what ‘Simplicity’ actually means (and feels like) when consciously understood and applied to our day to day work. I did research great deal of books & articles that detail the importance of and offered tips to “keep things simple”. “Laws of Simplicity” (by John Maeda) stood out for two reasons: 1) Categorization of different principles in to 10 laws (embodiment of a law itself!); 2) Clear and practical uses of each of these laws.

Here I present my views of some of these “Simplicity Laws” that I found highly beneficial in the process of “Analysis”. I hope the same is true for you as well!

Reduce

Analyzing a business problem requires a thorough research about existing process & practices, emerging trends, competition and current capabilities. This could well lead us into a minefield of information. If not carefully managed, we would be trapped in this minefield and eventually lose out by delivering incorrect or inefficient solution.

Thoughtful reduction of what I call “3D” would help in differentiating the “noise from the sound” and leave us with clear, relevant information

Data which is irrelevant
Discussions (with stakeholders) that are futile
Documentation of every little fact that comes our way

Organize

As we work to identify different solutions for a business problem, variety of information shall be at our disposal. Applying the first law of “Reduce” in the hope to overcome the problem of “Disconnected Data” may not work most of the time, because it only eliminates what we do not need. This is when we must activate our brains to look for patterns in information and assimilate information. This creates a systematic approach to “clear the clutter” and also help us find information when we need it and as we need it! As the book “The Art of Organizing Anything” (by Rosalie Maggio) captures, it is possible to organize anything. Why not organize what we analyze? And organizing information as soon as we find it definitely helps in the long sprint!

Learn

Have you ever been in a meeting in which you did not get what is discussed? I know exactly how it feels – puzzling. Such puzzling could trigger thoughts that range from irritation, helplessness to fear of the unknown! You probably guessed it – domain knowledge is necessary to be a successful analyst but is not the only one. With the barrage of technological innovations happening around us, which I think is great, we must strive to learn “new stuff” all the time. Competition is the other factor that “forces” us to learn something, but that does not cause as much excitement as our proactive ability!

Trust

Ofcourse! If we cannot rely upon our co-workers, nothing would ever get accomplished at the workplace. So the obvious is beside the point. As analyst, we must identify trust-worthy “source of information”. Don’t we use Google to search for most of the information? Do we trust all the 38,10,00,000 results that Google throws up for the word “analysis”? As we gather information, note down the source of that information. Revisit the source (probably while Organizing) to check the allied information, acceptance and authenticity.

If interested, I welcome you to explore the other laws of simplicity and share your valuable thoughts on how the below laws impact analysis OR even do they?!

Time
Differences
Emotions
Failure
Context
The One – that combines three keys: Away, Open and Power

Don’t forget to leave your comments below.