Skip to main content

Tag: Planning

Specifying Requirements for Outsourced Projects

Written by Karl Wiegers on . 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.

Wiegers Sept9

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.

Planning is Not a Solo Activity

Written by Duncan Watts on . Posted in Articles.

Planning is something I have a love/hate relationship with. Done properly it is a thing of beauty: The team working together to plot a common path through a thicket of issues. An initially vigorous debate that eventually settles down as objections are countered and agreement is reached. Done badly it’s a dreadful sight. A Project Manager sitting alone at a computer cursing Microsoft Project.

Related concepts

It’s important to clearly distinguish a number of related concepts:

  • Planning is an activity in which the actions to be taken are developed in advance;
  • A Plan is some form of documentation that communicates the result of the planning activity;
  • Microsoft Project is a useful tool for producing some of the components expected in a plan, such as a Gantt[1] chart.

It should be clear from these descriptions that planning must come before a plan, and that entering scheduling information into Microsoft Project does not substitute for having an actual plan.

What’s in a plan?

A plan should include everything you need to communicate how your goals will be achieved. It should not contain unnecessary boilerplate as plans may change regularly and need to be easy to keep up-to-date.
Importantly, not every plan needs the same level of detail nor to cover the same timeframe. The project team requires a plan that goes into detail about the current stage, but can be vague about future stages, so they can coordinate their work. This kind of plan should be updated regularly as the team gains more experience and progress, or lack thereof, becomes apparent.

The project board needs a simple plan that shows a schedule of major milestones and deliverables for the whole project, and a high-level indication of how these will be achieved with the available resources. This kind of plan should be light on detail – because the detail isn’t generally known yet – and should only be updated at the end of a stage or in response to an exception.

A classic PM mistake is to try to have both these levels of plan combined together into a single document – or worse into a single schedule in Microsoft Project. The problem with this is that the project team is never allowed to change “the plan” because the PM fears the project board will think that “the plan” has changed.

It hasn’t of course, because in reality there are different plans with different purposes, and at different levels of granularity. But now the PM is stuck, and planning, if it occurs at all, is now off the record.

Who does the planning on your project?

On many projects it is assumed that the Project Manager does all the planning. This is a grave error[2]. The people who should be planning the work are the ones who will perform it. There are at least there reasons for this:

  1. Even a Project Manager with extensive experience of all the tasks to be performed is unlikely to be able to estimate accurately without knowledge of the capabilities of everyone else on the team[3];
  2. A team member who was not involved in planning her work cannot reasonably be held to a plan devised by someone else. Buy-in to the plan requires participation in creating it;
  3. Except in the simplest case, a plan is not a list of independent tasks, and therefore everyone involved must plan together to identify dependencies and gaps.

The Project Manager owns the plan, and should ensure that the results of planning are captured, documented, and can be used to monitor progress. But planning itself is a team activity. Get everyone in a room and work through what needs to be done together. Drill down until the key tasks are clear to everyone. Question assumptions. Repeat.

Plan well and prosper

Planning is not a solo activity. If you join a project and are given a detailed plan (or more likely a schedule) with your name next to various activities, ask when the next team planning session is.

Don’t forget to leave your comments below.

References
[1] http://en.wikipedia.org/wiki/Gantt_chart
[2] In mature industries this may not be the case, but IT is not a mature industry. If you don’t believe me ask yourself what other industry accepts a 60-70% failure rate for projects.
http://www.zdnet.com/blog/projectfailures/study-68-percent-of-it-projects-fail/1175
http://www.versionone.com/assets/img/files/CHAOSManifesto2013.pdf
[3] In some organisations the same team works together repeatedly on similar projects. In which case the project manager may be justified in doing all the planning. This is the exception.

Failure to Manage our Time is a Modern Ailment

Written by Michelle Symonds on . Posted in Articles.

Feeling like there are not enough hours in the day can be a major constraint for most business analysts. But what is the answer? Delegate more? Sleep less? Become more efficient? There are plenty of answers that crop up but successfully managing your time when there are so many pulls on that time takes steely determination. How many of us are strong enough to switch off our phones and ignore our emails, even for just a couple of hours a day? And yet that simple exercise could help us reduce the time pressures we are under.

So instead of letting a lack of time overwhelm you, try some of the following tactics to help you become a more organised, more efficient and less stressed business analyst:

1. Focus on the Priorities

A list of tasks or a project schedule without any meaningful priorities attached to each activity and any dependencies between tasks recorded is of little use to anyone. After all what happens when further tasks need to be added; they clearly can’t just be tacked on at the end of the list, especially if there are inter-dependencies.

You may think you do have a prioritised task list, but projects are constantly changing, so your priorities will have to as well. Business analysis and project management are inextricably tied up with change management so changes need to be embraced, whilst at the same time controlled so accept that priorities will change. 

Review the priorities regularly (the most appropriate time period will depend on the size and complexity of the project you are currently working on) and be prepared to drop one task in favour of another. However, take the time to really determine what the priorities are; the person shouting the loudest does not necessarily have the most important requirements.

2. Delegate

This is fairly obvious but many of us are still bad at delegation, but don’t try and do everything yourself; others in the project team may actually relish the opportunity to take on responsibility for running a meeting or preparing documentation – after all, it is all good experience that will help them develop their own careers. Concentrate on what you are good at not the minutiae of administration. If you are lucky enough to have a Project Management Office (PMO) then make use of them, that’s what they are there for.

3. Time Box

Allocate time limits for everything from meetings to producing specifications and reviewing documentation and any of the other regular activities you engage in. Meetings, in particular can eat into your time and often with little gain compared to the time expended. By limiting every meeting to an hour or two (or whatever is appropriate for the topic to be discussed) you will ensure everyone present focuses on that topic and does not use the meeting as an opportunity to bring up their latest gripe.

For short, regular meetings, such as status updates, hold a “stand-up” meeting in a room without any chairs. You will be surprised at how quickly and efficiently everyone will discuss what they need to when they can’t sit down (and did you know that standing up is actually good for your health!).

4. Put it in Black & White

Daily or weekly To-Do lists and notes of ideas and inspiration can help clarify your thoughts and objectives so you focus your efforts on what really matters. You can jot things down in a notebook or use a spreadsheet or one of the many apps available for your phone, whatever method you prefer. Treat your notes as an aide-memoir – they are not meant to be a detailed task list or a detailed solution to a problem. And there is something very satisfying about crossing things off a list once they are done.

5. Technology-free Time

I remember a time when everyone thought technology was going to give us lots of spare time, and it does in many situations, but there are other ways in which it eats into our time. Reading emails that we are copied into when really we are not required to join in the discussion, reading the daily newsletters and updates that populate our inboxes; being active on social media networks.

Start to regain some of that time by unsubscribing from all but the essential email lists you are on – with the time you will save you can schedule time to catch up with your favourite sites without all the unnecessary emails clogging up your inbox.

Once you have cleaned up what you receive, set aside a specific time each day or week to ignore your emails – don’t be shocked, in fact, you may be surprised how even “important” emails resolve themselves if you don’t respond, after all what would happen if you were on holiday or in hospital, someone would have to sort out any problems. And if you are worried that you will lose some authority by not instantly responding to emails then your career is built on flimsy foundations anyway.

And as for social media, there are extremely useful tools out there just make sure the benefits you gain from their use outweigh the time invested. And, again, schedule time in your day when you use it rather than constantly checking for updates or constantly posting updates. A well-thought out post/share once a day is just as valuable as constant activity that says little of value.

6. Sit Back and Think

Instead of lurching from task to task or crisis to crisis take a step back from the “doing” and try some thinking – think about what is really important for the success of your current project and your long-term career. Taking the time to think through a problem, rather than rushing into activity, so that it looks like you are resolving the problem, can actually help you to deliver a better solution. Often too little time is spent thinking or planning because this is not perceived as “real” work when, in fact, it is the thinking time that will produce the best results.

These are just some strategies that business analysts can try in order to regain some time and some order in their lives. In the meantime I am going to try and take my own advice…

Don’t forget to leave your comments below.

Shift Your Business into Drive – Focus with a Balanced Scorecard

Written by Richard Lannon on . Posted in Articles. 1 Comment on Shift Your Business into Drive – Focus with a Balanced Scorecard

To achieve a balanced business perspective consider using a Balanced Scorecard as part of your strategic planning initiative. A Balanced Scorecard is an approach that is used to align your business to the vision, mission, core values and strategy of the organization. The emphasis is to turn strategy into forward thinking actions that the senior team can implement against key performance indicators. To embark on a Balanced Scorecard, the company must have a mission and vision and know their financials, the present business structure and levels of employee expertise. They must also have extensive knowledge regarding customer satisfaction levels.

There are four key elements in a Balanced Scorecard: Customer, learning and growth, financials and business processes.

  1. Customer: Research has shown that having a customer-centric view focused on satisfaction is one key to success. If the customers aren’t happy they’ll move on. Good or poor customer performance is a leading indicator for the future success or failure of a business. The ultimate question is this: What is the value proposition that you deliver on in your customer markets? Knowing your value as defined by the customer and having a clear understanding of what your customer is willing to pay is essential. This part of the Balanced Scorecard helps you focus on your markets and customers.
  2. Learning and Growth: This part of the Balanced Scorecard includes your business culture, employee and business attitudes, self improvement initiatives and your investment in employee development. It is known that successful long-term businesses invest in the success of their people. High performance is driven by dedicated happy people. Most organizations today are operating on a knowledge platform. It is the unique knowledge of the people that keeps things going. Unfortunately, when people leave their knowledge leaves too and getting it back is painful. Things to consider include: employee satisfaction, retention, skills, experience and aptitude and the business’s beliefs, values and attitude. Ask yourself this: What kind of infrastructure is needed to foster long-term business success enabling us to grow and change to meet ongoing demands?
  3. Financials: Data on company financials is important. The key is having the right kinds of data along with timely and accurate information. For management, just having return on investment information might not be enough. As data becomes more centralized, other financial data and key performance indicators become important. For example, consider cost-ease-benefit analysis or risk analysis to consider long-term impact. This is a slight shift that changes thinking.
  4. Processes: This refers to the internal processes of the organization. Most businesses have a maturity line when it comes to processes. They are usually chaotic, reactive, proactive, service or value providers. These can all be measured. The management team needs to know what is working and what is not working in relation to the customers’ needs and the business mission. Understanding the present state of business processes allows for a focus on a desired future working state that will provide positive, measurable results for the business. The best people to do that work are the people who do the work. The key is to know what existing and future business processes must be focused on to excel as a business.

Having a Balanced Scorecard that is aligned to the mission, vision, core values and guiding principles of the business is an important part of your success. If constructed well it becomes part of a strategy map and a communication tool that allows you to easily share your work and progress with stakeholders. With a Balanced Scorecard you can forward think and create the success you deserve.

Don`t forget to leave your comments below.

7 Habits of Highly Effective Business Analysts

Written by Angela Wick on . Posted in Articles.

Highly effective BAs, regardless of their skill level or years of experience, consistently hone their craft. Guided by curiosity and passion, great BAs are always on the lookout for growth opportunities—ways to strengthen and sharpen their skills.

This focus on continuous professional improvement goes far beyond attending an annual conference or workshop. Instead, effective BAs develop daily habits that demonstrate leadership and expertise.

So, I’ll borrow Stephen Covey’s popular “seven habits” framework to discuss the recurrent behaviors that support excellence in the business analysis profession.

Although I refer to these as BA habits, they can be applied to most professions. So, whether you are a project manager, a tester, a techie or a trainer, think about how these habits can help you become a leader in your organization.

Habit #1: Effective BAs engage stakeholders.

BAs need information, cooperation and trust from their stakeholders. Skilled BAs get what they need by building strong relationships. They engage stakeholders in a way that inspires engagement, creativity, collaboration and innovation.

How do you know if your stakeholders are engaged? Well, these are common issues on teams with weak stakeholder engagement:

  • Strongly conflicting requirements between stakeholders.
  • Stakeholders are silent; roll their eyes, sigh or multi-task during meetings.
  • Stakeholders do not contribute to the project. They don’t return phone calls, do not reply to emails, do not review project documents, provide resources, etc.
  • Stakeholders show up late for meetings, leave meetings early or skip meetings.
  • Disparate groups do not understand other stakeholder’s needs and benefits from the project.
  • Progress is slow.
  • Discussions loop in circles.
  • Decisions are difficult to obtain.

Do you see any of those things happening consistently in your organization? Effective BAs use their influence to create an environment that looks more like this:

  • Stakeholders have a shared vision and can communicate the vision to their team/s.
  • Stakeholders understand their connection to each other.
  • Stakeholders trust each other and the BA.
  • Stakeholders enthusiastically participate in meetings.
  • Stakeholders make themselves and their resources available to the BA as needed.
  • Questions, discussion and meaningful debates.
  • Proactive, 2-way communication

Habit #2: Effective BAs research new techniques.

Great BAs love discovering new tools that make work efficient, valuable and maybe even fun. Experts estimate there are more than 500+ BA techniques in use today—literally lurking around every corner. Here are a few ways to find them:

  • Read the BABoK! The IIBA’s comprehensive handbook describes 40 of the most common and useful BA techniques. Current IIBA members can get a sneak peak at BABoK 3.0 by participating in the public review process. 
  • Attend industry conferences and workshops. Full-day or multi-day training sessions give BAs exposure to a variety of new techniques, trends, and methodologies. Many training companies and universities offer BA training. IIBA and PMI sponsor events across the world.
  • Network. Connect regularly with other BAs. Ask them about new techniques. Find out what works on their projects. Solicit advice when you hit road blocks.
  • Observe others. Find a mentor. Watch your peers. Which techniques do they use regularly? Are they working? Why or why not? How could you make them better?
  • Borrow from other industries and professions. The most obvious example may be the lean processes project teams have borrowed from manufacturing. Are there techniques you could borrow from an elementary school teacher, a farmer, a scientist or an actor? Definitely!

Habit #3: Effective BAs experiment with new techniques.

Now, it’s time to put those new techniques to work! Stagnation and boredom are the enemy of an effective BA. Applying new techniques keeps BAs motivated, engaged and inspired.

Experimentation often invites risk, but there are many ways to contain possible fallout:

  • Start small. Try a new techniques on small, low risk projects. Apply the new technique to a small part of a big project.
  • Break it down. Find a way to break the new technique in pieces. Try one piece on an analysis or elicitation effort to see if it is works. Then get feedback and adjust course if needed.
  • Find your friendlies. Use a new technique with a small, friendly group of co-workers. Encourage them to give you honest feedback.
  • Set expectations. Let stakeholders know why you are trying the new technique.
  • Ponder plan b. Courage to try new things includes the possibility of failure. Think about the worst case scenario. What’s your plan b if the new technique fails?

Habit #4: Effective BAs plan to re-plan.

I run into so many BAs that get stressed out by estimating requirement deliverables. They often ask, “How can I estimate when I don’t have any requirements yet?” My answer: “We plan to re-plan!”

As the project needs and scope evolve, effective BAs revisit their estimates—they reevaluate and adjust as the project moves forward.

Every BA leader and PM I have talked to about this agrees. It’s totally fine to change the estimate and re-plan, just not at the last hour!

So, set expectations and share them.

  • Make sure the PM and other leaders understand that this is your best estimate based on the current state of the project.
  • Help them understand which factors will increase or decrease estimates.
  • Plan resources: What can you do in the early stages of the project to anticipate estimate changes? Who can you pull in if you get behind? What tools can you use to be more efficient? How can you manage busy SMEs to get good requirements?
  • Look at the value and risk of scope items and adjust the plan accordingly to spend more time on high value and high risk items.
  • If your incentives are based on estimation accuracy, then talk to your leader about re-planning and how it fits in the incentive plan.

Effective BAs know that re-planning will be required to protect the project value. They look at the tasks and deliverables like puzzle pieces that need to be flipped, turned, and shuffled until they all come together in their proper place.

Habit #5: Effective BAs use visuals, often.

In most cases, visual communication is more effective than text-heavy documents or verbal descriptions—humans process visual information more quickly and completely. Effective BAs understand the importance and efficiency of visual communication. They always look for new and improved ways to use visuals in their meetings, presentations and documentation.

Skilled visual communicators:

  • Create high-level conceptual visuals, low-level detailed visuals and everything in between.
  • Tailor their visuals to meet the needs of their audience. Does a CEO want to review a 20-page process model? Does a group of SMEs want to focus on the whole organization or just their piece of the pie?
  • Draw spontaneously on white boards when discussions start spinning.
  • Use visuals in virtual meetings too. They use virtual whiteboards, post-it notes, flow charts, etc.
  • Know that visuals do not need to be perfect. You don’t need to be an artist. You don’t need 100% accuracy on day one. A flawed visual is so much better than starting with a blank page.

Habit #6: Effective BAs develop Underlying Competencies.

Obviously, BAs need techniques and tools to complete their practical tasks, but they also rely on underlying competencies. The techniques are like the tools in the tool box, but underlying competencies (UCs) influence how the tools are used and how the techniques are applied. UCs are the artistry, the finesse, or the soft skills.

Effective BAs continuously refine their UCs in many of the same ways they develop techniques: research, training, observation, experimentation, etc.

Effective BAs maintain dozens of UCs, but here are a few of the most important:

  • Critical thinking and Problem Solving
  • Teaching
  • Leadership and Influence
  • Facilitation and Negotiation
  • Personal integrity
  • Organizational Knowledge

Habit #7: Effective BAs consider politics.

Politics exist in every organization.

In project work, politics usually play out during prioritization efforts: which work will get funding, whose projects fit into an implementation, which requirements get cut.

Skilled BAs don’t ignore politics, but they avoid playing. They work around and within them.

How do effective BAs walk this fine political line? How do they understand and manage politics without getting involved? Good questions. Here are a few ideas:

  • Build wide support to eliminate politics as a factor.
  • Always redirect the team back to the project value. Which requirements, timelines, bug fixes, testing strategies, etc. best support the goals of the project and value to the organization?
  • Gather data. In many cases, good data can tell as story that transcends politics and makes the right answer obvious.
  • Lead with empathy. Understand what each stakeholder is seeing, hearing, thinking, feeling. Use these insights to help you influence each stakeholder.
  • Understand the definition of success for each stakeholder.

Which habits make you a highly effective project professional?

Don’t forget to leave your comments below.