Tag: Best Practices

When Good is Good Enough

Written by Moana O’Neil on May 21, 2013. Posted in Articles.

It is not always necessary to achieve the best quality result or employ the best practice approach when implementing a project. Blasphemy you say?! Or perhaps this sounds very obvious?

As a Consultant Business Analyst, I want to deliver the highest possible standard of work. This is for myself, to protect my reputation in a very small market, my employer, for the same reason, and naturally the Client. So when confronted with the familiar request from a client of ‘we need X by Y’, X being ‘too much’, and Y being, ‘yesterday’, I prepared myself for the familiar conversation where I ‘re-set’ the expectations of the business to give them a good old reality check in order to be able to deliver a high quality result.

After much discussion, and adjusting the project plan, the team came to a point where the original timeline to deliver was cut by 50%, the approach was Iterative (read developing before requirements had been finalised), and we were still meant to be delivering by yesterday…sounds like the Perfect Storm perhaps?

So the end result? We successfully launched a new product to market in an ever competitive market, with minimal major defects (oh yes, there were defects). Let’s be clear, there were issues, namely rework of development due to changing requirements, requirements identified late and defects.

Yet the project was still considered a success by the Client. How did this happen? Here’s what I think:

Planning – No surprises
We planned, oh how we planned. The business grit their teeth as we took the (valuable and limited) time to lay out all the Risks, and consider the appropriate approach. We looked at the options around descoping or phasing delivery of functionality to achieve the same or similar benefits in the time available.
All of those things proved valuable and contributed to the success of the project. However of MOST value was the time taken to identify the comprehensive list of Risks, which became largely Issues. Because we had highlighted them all early on and the Business Sponsor and Owners were aware, there were no ‘gotcha’ moments, and all were mitigated to resolution or to a point where it was not a show stopper.
The Right Team – Skills and Experience
It sounds so simple – but we have all felt the pain of having team members that don’t have the appropriate level of skill or experience or both. Yes, having the right team can be difficult to achieve, but when it all comes together, magic can happen! Specifically we had a QA Lead, Solution Architect, Technical Lead, and a humble BA that had experience both in the relevant industry, and similar projects. Were things missed? Yes, however there was enough support in the team, and coverage of the key functional areas to get us through.
Number One Priority
To achieve this project within the appropriate timelines, compromises had to be made. The old adage ‘Something’s gotta give’ was so very true. So we asked and the business approved a portfolio review, projects were re-prioritised, and while there were clashes on occasion, we managed to get there.
Business and Project Team Aligned
The Business and Project Team were aligned. My biggest feeling of anxiety was around not being able to provide the appropriate level of detail in the requirements up front in order to avoid ambiguity. However this Risk had been communicated up front, and QA, IT and the Business Owners knew this – and we communicated, we collaborated and the business were responsive when we needed clarity from them. We did 80% fantastically, and the remaining 20%…not so…but 80% got us through.

Conclusion:

So we got there! Result! Did we have defects? Yes. Did we have re-work? Yes, but not enough to be restrictive. Was there luck involved? Absolutely! Would I employ this approach at every engagement? No.

But doing just enough, still delivering to the benefits and to see it be successful was a great reality check. It has allowed me to understand what is possible given the Perfect Storm, and added a different perspective to my perhaps formerly idealistic view of things in the world of Consultancy. I expect the next assignment I go into will provide me with anecdotes that totally contradict all that I have just shared, but hopefully it at least provides fodder for some great blog comments!

Don’t forget to leave your comments below.

To BA or Not to BA

Written by Gurpreet Singh Kharbanda on April 2, 2013. Posted in Articles.

The article presents my perspective on the best practices of the trade, including things that a BA should keep in mind while carrying out his or her responsibilities.

I have had a number of people ask me what it is that a BA does in any software engagement. Is it really important to have a BA for every project? Is this a generalist or a specialist skill? While answering these questions, I found myself struggling to restrict the tasks to be carried out into one domain; to clearly categorize the required skills as the must-haves and the good-to-haves. Like everything in life, here you also have a choice to do it for the sake of it and get it done, or do it with the intention of adding value to multiple stakeholders. As this role entails a unique advantage of interaction with people at every stage of SDLC, you have a chance to get a holistic view. The role offers you an opportunity to be a “requirements collector” or something more.

Through this blog I am going to share my understanding of this universe and what can help you excel as a BA.

Facilitate reverse flow of knowledge and experience: The client, for sure, can have a much better understanding of their business, but the BA often has interface with a team (or at least some members of the team) who might have worked in the same domain for multiple clients. This exposure more often than not helps them develop insight regarding solutions. Encouraging brainstorming and generating ideas by collaborating with them gives you an opportunity to act as a conduit to pass these on to the client and help define and refine the solution. However, using your understanding of the business and their inclinations, you must filter these ideas so that they end up having higher relevance to the client.
So next time your team comes asking questions about the implementation details, respond to their questions with your questions to elicit answers from their experience.

A caveat here though is to be attentive to the rationale behind the suggested approaches, which might as well be rooted in simpler implementation, reduced effort, and the tendency of taking a path of lesser if not of least resistance.
Identify the opportunities to pitch in: When you hear “I don’t know” or a tentative tone a few times while discussing requirements or solutions, that’s your cue to be a hero and you should not miss such opportunities to shine. This is where your research/domain expertise can help you earn a couple of extra brownie points. If you have spent some time going through the trends, the best practices and the common pitfalls, such homework is bound to help you. Being aware of the possible solutions in the same space can help you pick the relevant features from them and customize them to meet your needs. After all, getting inspired is no crime!
Similar situations can also be exploited to cross-sell solutions, if you are aware of the capabilities/strong practices of your own organization. This is a prospective win-win situation for everybody. Your organization benefits from the increased business, you get to work on your revenue-pulling skills (which are obviously highly appreciated) and the client gets integrated solutions without having to interact with multiple vendors (which can get complex at times).
Know your customer…and their customers: Spend some time understanding your client’s business, their competitors, their concerns and their KPIs. Such measures are greatly welcomed and appreciated. This is that extra mile you could go to delight them and win them over. Knowing the customer’s customer is the best thing you can do for yourself as this helps you put things in perspective. You are better able to grasp the context and priority of your client’s needs. This helps you to create value for them as well as build domain expertise for yourself.
Give up the ego: Don’t be too hung up on your ideas. You must have heard this a zillion times but it is still hard to practice. Do more listening and have an open mind. Learn to appreciate others’ views and try stepping in their shoes rather than concentrating on selling/pushing your own ideas. At the end of the day the best solution is the one that makes the clients happy, and that is what should be your focus.
The same applies when you interact with your own team as well. You will end up working with a better designation, never underestimate the importance of wisdom that comes from experience. Humility is indeed a virtue.
Balance the Act: When the clients’ expectations are of ultimate flexibility from the team and the development /delivery team’s tendency is to avoid changes to the requirements late in the development cycle, someone has to play the moderator to get the required time from the client for the team by pushing deadlines, and cajoling the team, on the other hand, to absorb the changes, which are the client’s priority.
Work your ancillary skills: While mastering of the support tools (PowerPoint, Excel, and Visio, etc.) may not fall under your immediate responsibilities, these are certain to help you differentiate yourself. Be aware of the utility tools available that can help in performing your tasks effectively. You can find lots of software assistance to create UI mockups, functional prototypes depicting flow, requirements management, etc.
Some coding/architecture knowledge won’t hurt you either. It helps you to connect with your own team and earn their respect, and to have them consider you one of them and not someone who is from a different planet speaking a different language. Another way it benefits you is you get to gauge the effort estimates that you might have to deal with every now and then.
Be a people person: Healthy relationships with other teams working with the client (UI design, development, etc.) will help you ensure smoother execution of the project. Synergy is the keyword here. Don’t try to offload your responsibilities. While you could implement easier processes at the expense of their increased efforts, it is not a recommended path. Be ready to be of help and work together even if it goes beyond your call of duty. Such will be the instances that will help you grow professionally and enhance your skill set. This could be the best hands-on, cross-cultural training that you might receive — a lot better than classroom training.
Comply with the processes: Where there is the thrill of being in the fore with the client, the action of thinking on your feet, there is also the not-so-happening part of this role, which involves sending MOMs, documentation, change management, versioning and scoping, etc. You might hate this part, but the fact is, when bad gets worse, you will find these things coming to your rescue. This comes with the bonus of making your own delivery folks happy about your work, as they are constantly under pressure by the auditors and quality folks.
Don’t go soft on your Soft-Skills: There is no way you can get away without these in your ammunition. Facilitation, conflict resolution capability, diplomacy, presentation skills, etc., are all required in proposing your ideas and countering others without making them uncomfortable. These are most important when you present ideas and negotiate timelines or approaches with your client.
Create reusable resources: Using your comprehension of the business and experience to generate artifacts that can foster the understanding in the team, transition of new resources is another good activity. Try translating your tacit knowledge to explicit knowledge by documenting it as process flow diagrams, systems’ interaction diagrams, etc., so that others can take advantage of it.

Practicing the points mentioned above will take you a long way. A couple of characteristics that will prove to be the icing on the cake for you are being crystal clear and concise in your communication and documenting requirements. Nothing should be left to the imagination of the developer. Your knowledge about the client’s needs and priorities should ensure that no grey areas are left with regards to requirements. Above all, be ready to don multiple hats: of a PM, a QA resource, of a QA lead, a client, etc. And be aware that being part of a project leadership team along with the Project Manager and Tech and QA lead, your attitude toward problems and work is bound to have a rub-off effect on the resources working with you. As Uncle Ben very rightly told Spiderman, with great power comes great responsibility.

Don’t forget to leave your comments below.

The BA Practice Lead Handbook 4 – So You Want to be a BA Practice Lead? Are You Ready?

Written by Kathleen B. Hass, PMP on February 26, 2013. Posted in Articles. 1 Comment on The BA Practice Lead Handbook 4 – So You Want to be a BA Practice Lead? Are You Ready?

In previous articles in this series, we have discussed the need for mature Business Analysis practices, what value key stakeholders can expect from BA, and the need for a holistic approach to implementation of Business Analysis. In this article, we discuss how you as BA Practice Lead/BA Manager can ensure you are ready to lead the effort to implement and sustain a BA Practice.

Diagnose your Leadership Capability

Building a new business process such as Business Analysis is a challenging endeavor. Your initial challenge is to gain executive sponsorship and organizational alignment up front. Do you have the power and influence skills to take a comprehensive view that is aligned with your environment and decision-making practices?

Your Power and Influence

According to D. Bell, author, educator, social media producer: business + politics = power. Make no mistake: organizational politics will influence your BA practice in multiple ways. Politics are defined as the collection of internal structures of an organization that deal with power, influence, and decision making. We all say we hate politics because it is often a negative influence in our lives. Actually, politics is neither good nor bad, it just is. Think of positive politics, positive power and influence. Things happen when politics works. Decisions are made. Projects move forward. Deals are cut. Goals are met. How can that be bad? Your power is directly related to how well you negotiate the politics of your organization.

The positive politician uses influence rather than authority or manipulation to achieve tasks or goals. Your ability to act as a positive politician will result in beneficial results for your team, for your organization, and ultimately for you. As a positive politician, start from a solid foundation from which to influence including: status, reputation, credibility, trust, integrity, consistency, knowledge. Business analysts possessing these characteristics emerge as leaders. People want to follow natural leaders.

Devise strategies to negotiate your organization’s politics by building your influence capabilities. Capture the strategies and tasks to achieve the strategies in your Political Management Plan. Your plan might be a simple table like the one below. Strategies may include:

Enlist the help of an executive sponsor
Organize and chair your steering committees
Make yourself an expert, increase your credibility
Promote yourself and Business Analysis
Manage BA benefits (ROI)
Manage virtual alliances
Facilitate, negotiate, and build consensus
Manage conflict
Facilitate consensus and confront issues head on

Your network

To build a positive network of supporters within your organization, identify your customers and stakeholders that: provide budget to your BA practice implementation project, provide oversight, provide requirements, provide input, get output, depend on your deliverables, benefit from your BA Practice success, and/or suffer from its success. For each key customer/stakeholder, capture the following information:

Role
Awareness
Opinion
Importance
Current level of support
Level of support needed
Identify the issues and concerns regarding the BA Practice that are important to each stakeholder
o What’s in it for them?
o What do they need to view the BA Practice positively and actively support it?
What actions will you take to increase the support of your most important stakeholders?
Devise strategies to negotiate your organization’s politics by building and sustaining a strong supportive stakeholder network. Capture the strategies and tasks to achieve the strategies in your Political Management Plan. It might look something like the simple table below.
Devise your strategies to lessen the impact of those who may negatively influence your BA Practice and leverage those who are positive about you and Business Analysis.

Assess the Environment

Lastly, identify organizational and cultural risks to your success, and devise strategies to manage the risks. Update your Political Management Plan accordingly.

Assess the landscape…

Environmental/organizational issues that are constantly at play
The amount of change the organization is undergoing
Political games/maneuvers that are underway; power bases and power struggles
Recent leadership changes and those that are anticipated

…and How Business Analysis fits

Is the business case for your project and/or for a BA Practice solid?
Is implementation politically sensitive?
Are there major political implications?
Is there impact to the core mission?
Do you have a strong executive sponsor?
What are the unspoken expectations?
What is the decision-making process?
What are the cultural norms?
Is the communication and coordination effort challenging?

How can Consultants help?

If they have been where you are, bring in consultants to:

Help assess organizational readiness and support
Review your plans
Do a risk assessment
Coach you through the process
Gain approval and consensus on the way forward
Form a guidance team/steering committee to involve upper management in the effort

Putting it all Together

So what does this mean for the Business Analyst?

If you are trying to implement BA best practices, methodologies, frameworks, and enabling technologies on your project, good for you! The influence capabilities described in this article apply to you as well as to your

BA Practice Lead. Work with the key leaders on your project to examine your collective power and influence, and the landscape within which you are operating, and develop a Political Management Plan.

So what does this mean for the BA Practice Lead?

This article presents the case for a BA Practice Lead to examine political implications including your influence, power, support, and environmental issues. Diagnose your political strengths and gaps. You need strong influence skills to get people to want to support your effort. Develop a Political Management Plan to increase your ability to negotiate the organizational politics and your personal power and influence to achieve your goals.

Don’t forget to leave your comments below.

Ignoring Complexity is Not Simplicity

Written by Hari Shankar on February 19, 2013. Posted in Articles.

Simplify. This seems to be the buzzword in the projects.

Business owners demand it. Project Managers utter it. Architects revere it. Unfortunately IT seldom delivers it.

How can Business Analysts contribute to the goal of simplification? Let us begin with the definition.

What is Simplifying?

Simplifying tends to get misunderstood. Project Managers and Business Owners often treat it at a superficial level. Business Analysts are encouraged by project stakeholders to ignore complexities and focus on simplistic situations. Simplifying is not about being reducing capability. It is about delivering more by choosing smart solutions.

“Very often, people confuse simple with simplistic. The nuance is lost on most.” Clement Mok

For instance, if there is a significant data integrity issue in a project striving for automation, the issue of data purification and reconciliation is often ignored. While the automation functionality may be delivered (often at a high cost), automation ratios continue to suffer.

Simplifying, in the actual sense, involves taking a complex process and re-engineering them to manageable entity. It requires delving deep rather than staying superficial. Simplifying necessitates focus on non functional requirements such as: Scalability, performance, reliability, security and inter-operability.

Techniques for Simplifying

“Simplicity is the ultimate sophistication.” Leonardo da Vinci

Some of the problem solving techniques that can be applied in various business analysis competencies are highlighted below:

Systems Thinking

One of the common problem-solving approaches, useful especially in the initial stage of the project, is to understand the eco-system of the problem domain. As part of enterprise analysis a holistic view of the components of the domain and their interactions needs to be mapped. Context diagram is a handy tool in documenting the results of the systems thinking. System thinking helps to simplify by focusing on:

• Interdependencies (cause effect modelling)
• Goal alignment (ensuring all value streams work towards achieving common goals)
• Convergence (removing redundancies and improving system performance as whole).

Process Patterns

At a business analysis level, identification of process patterns helps to standardize and improve consistency. All business domains over a period of time tend to exhibit entropy. Identifying the essential process patterns helps in implementing control mechanisms that will reduce process deviations.

For instance a campaign management process, irrespective of the channels that is used (direct marketing, phone, internet etc) would have a process pattern like:

Identify target market, contact target customer, promote concept\educate customer, provide offers and initiate fulfilment.

Process patterns help to maintain consistency, minimize and reuse design and improve throughput. It engenders focus and removes activities that do not contribute to the goal of the process.

Think Data

Data elements are the fundamental building blocks in any system. They tend to get more complicated and maintenance intensive, causing data attrition. In a study done by IBM, data quality even in best maintained system has an attrition value of 2%..

Business analysts can simplify the way in which data structures are defined, maintained, displayed to the users. Identifying core and meta-data relevant to business is an integral part of requirements analysis. Naming standards help reducing the profusion of multiple terminologies.

Organizing data structures smartly ensures that business processes operating to maintain the data can be simplified.

For instance, in a telco domain, if the fulfilment process does not define data structures for service level agreements consistently, service assurance processes will suffer.

And Finally

Business Analysts can gain significant benefits by simplifying the way requirements are documented and communicated.

Using relevant diagrams, requirements management workflow tools, modelling data analysis and presenting them innovatively to stakeholders is a critical component of business analysis.

User stories, scenarios and narrative techniques can help the reader to engage and understand requirements better.

Taking a leaf out of Ernest Hemmingway’s book might perhaps help: “My aim is to put down on paper what I see and what I feel in the best and simplest way.”

Don’t forget to leave your comments below.

Seven Common Mistakes with the Daily Stand-up Meeting

Written by Greg Smith on December 18, 2012. Posted in Articles.

The daily stand-up meeting, also known as the daily scrum, may be the best of all of the agile practices. Why? Because it meets three criteria:

1. It’s easy to start using
2. It can often be used without other agile practices
3. It provides great value

Stand-ups can be interjected into waterfall teams and they can be used without converting to iterations or other common agile practices. From an adoption perspective, the resistance to using stand-ups is low. From a value perspective, teams quickly see the how the stand-up identifies risks and issues early. The stand-up gives them more time to react and still hit their goals.

As good as the stand-up meeting is, if done incorrectly it can do more harm than good. As an agile coach I have found I often skimp on stand-up training because it seems so simple. But this skimping has come back to bite me several times. How have I been bitten? By the seven common stand-up mistakes below.

Mistake # 1 – Not Standing (the daily sit down)

Teams usually stand when they first start doing the daily stand-up because they have just came out of agile training and they were taught to stand. But as time progresses it is common for some teams to assume standing is a formality and they start sitting more and more. This especially common if the meeting is in a conference room where chairs are available.

Standing is not a formality but rather a key success factor in establishing collaboration and keeping the meeting short and effective. How can you keep the team standing? Here are some tips that usually help:

Try to do the stand-up where chairs are not available.
Keep the team focused on the three key questions: What did you do since we last met? What will you do between now and the next meeting? Do you have any blockers or constraints that are impeding your progress? It is common for team members to explain their impediments in detail, and for a dialogue to start up between a few team members on how to resolve the impediment. This is fine if a solution is agreed to in a few seconds, but usually this a long conversation that ties up the whole team when only a few team members are needed. So as a Scrum Master, coach, or team member, get select team members to work impediments together after the stand-up.
Use a physical status wall (covered in mistake # 5 below).

Mistake # 2 – Team Members Not Showing Up On Time

Many teams struggle with team members drifting into the stand-up, often 5 to 10 minutes late. This contributes to the issue noted above, not standing, but also demonstrates a lack of personal discipline. Here are some tips for addressing the late arrival issue.

Pick a time of day that the team all agrees to, to have the stand-up. Sometimes management will ask the Scrum Master to have the team meet at a certain time, but I have found it is better to meet when everyone has arrived at work, and at a time the team all agrees to.
Get support from line managers. Agile is about team self-management and self-discipline, but everyone does not arrive at this state at the same time. If you are a Scrum Master, work with all of the managers who team members work for, and get agreement that the daily stand-up is important, and that punctuality is important. Line managers can emphasize these values when they do one on ones with their team members.
Provide a buffer between meetings that occur before the stand-up. If there is another meeting that precedes the stand-up, make sure the stand-up is not scheduled when the other meeting ends. Instead add a buffer of 10 to 15 minutes so that the stand-up is not impacted by any upstream meetings that runs over.

Mistake # 3 – Allowing Distractions

Daily stand-ups are ineffective if the team is not focused during the stand-up. Here are some tips for keeping the focus:

Location, location, location. If you do your standup meeting in the wrong location the team will get interrupted by passers by, or be distracted by eye candy such as the street below. Pick a location without chairs, some level of isolation, and if possible no windows.
Set a team norm of no cell phones or laptops during the standup.
Focus on good meeting etiquette – no side conversations or whispering.

Mistake # 4 – Updating the Project Management Tool During the Stand-up

Are you using an online tool to track project status? Maybe Mingle, Rally, or VersionOne? Many times the team will stand idle while someone is updating the tool during the stand-up. Try to avoid this at all costs. Have someone take hard copy notes and update the tool later, or even better, use a physical status board and have team members physically update their tasks during the daily stand-up. Remember that the tool serves the team, the team does not serve the tool.

Mistake # 5 – Not Using a Physical Status Wall

I love electronic project management tools. They let me consolidate information and do reports across a portfolio of projects. But the tools can impede collaboration during the daily stand-up. If one person is projecting the virtual status wall from an electronic tool, and discussing it with the team, the team often becomes an audience and just listens. However, if you have a physical wall with task cards, team members move and update their physical cards during or before the stand-up, which leads to much richer discussion and interaction. You can use an electronic tool in parallel (most of my clients do). It may be a little redundant, but the value a physical wall provides offsets maintaining 2 tools. And it will lead to a better stand-up meeting.

Mistake # 6 – Not Having a Dedicated Team Room

You may be wondering why you need a dedicated team room for a stand-up. You do not need a dedicated team room for the stand-up meeting, but you do need one for a good stand-up meeting. Confused? Here is the scoop. If your team is distributed all over your campus, and they come together physically each day for 15 minutes, do you think you can get them to only discuss status? I have not been successful in doing this. Developers and testers will want to get into testing details during the stand-up, user experience wants to talk to developers about screen details, and so on. If you have a dedicated team room, team members can talk about the construction details all day long, and they will not need to deviate from the stand-up status/impediment discussion.

Mistake# 7 – Not Using a Stand-up for Distributed Teams

Most companies I work with have team members in the United States, India, and China. These teams will often tell me they cannot do stand-ups because everyone is in different time zones. I understand this issue but I also understand that we undertake a lot of risk if we do not communicate daily. To get around this issue I have teams do the following:

Do a stand-up meeting at each location. At a minimum get team members synchronized at each site
Have one team member from each team work a staggered schedule. These team members on staggered schedules can do a video call or audio call to synchronize each day, and then take that information back to their local teams.
Use electronic tools to share status details. Electronic tools really show their value with distributed teams. Everyone can see the status information around the world, as soon as it is entered.

Follow these steps and you will establish a sound daily stand-up process, which will provide a great foundation for all of the agile practices you use with your team.

Don’t forget to leave your comments below.