Tag: Tips

7 Habits of Highly Effective Business Analysts

Written by Angela Wick on June 9, 2014. 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.

Business Analysis: Sharing Your Knowledge: Why and How

Written by Aaron Whittenberger on May 26, 2014. Posted in Articles.

Often, through their normal daily work the business analyst learns new knowledge about systems, business processes or the organization as a whole. In doing business analysis tasks on a daily basis, a business analyst investigates systems; whether through documentation analysis, interface analysis or interviews with system users or subject matter experts (SME), they learn how systems operate and how the business uses the system(s). Business Analysts are often called upon to document business processes, so they investigate those business processes through interviews or surveys of those involved in the process. Through Situation Analysis, Capability Gap Analysis, Feasibility Studies, SWOT Analysis, Market Research or Organizational Change Readiness assessment to implement a new project solution the business analyst learns about their organization and the business environment in which it operates.

All too often what happens when the business analyst leaves the team or organization is all that learned, and now tacit, knowledge leaves with them. Then comes the unpalatable task of replacing the business analyst and bringing the new person up to speed with the team. What can never be regained is that knowledge that left with the previous business analyst. Wouldn’t it be great to keep that tacit knowledge?

As the exiting business analyst how can you leave that knowledge with the team as you move on to other opportunities, especially when those opportunities are outside the organization? Do you want to spend the last two weeks on the team trying to hurriedly document all your tacit knowledge? Where do you store it; in what format? Let’s look at a better way.

An Internal Body of Knowledge

An internal Business Analysis Body of Knowledge is a centralized, electronic knowledge repository from which the entire business analysis team may draw knowledge. Centralized to one business analysis team or across the organization; who is this knowledge base to serve. Once you determine who your customers are, you can determine where to store this knowledge base to be centralized; and you can consider such things as security and access. You can determine if this should be stored on a shared network drive, SharePoint or another document repository.

Start from the beginning

Don’t wait until your final week or two in this role to try to leave all your knowledge with your co-workers. Start from your first weeks on the job. As you investigate and learn these systems, business processes and the organization start documenting what you learn about things. It is very difficult to document years of knowledge in your final week(s) on the team; so start soon after you join the team. Document as you learn. This also helps to ensure that important items don’t get forgotten.

Start Small and Grow

Egypt wasn’t built in a day, so don’t feel that you have to build an entire knowledge base in a week. If you start soon after you join the team then you won’t be rushed to build your internal body of knowledge in a week or two. You can build it over years of learning. Start from the first system or business process that you investigate. Document one system or business process and store that in your centralized place. There is your start. Add each system, business process or piece of organizational knowledge you learn while you are in this role and watch your body of knowledge grow. As the knowledge repository grows, you build the structure of the repository.

Start Yourself

You can bring the idea of a centralized knowledge base to your team and try to get buy-in; or you can just start yourself. You may have to determine what the team or corporate culture is to determine if you ask for permission or beg for forgiveness. As a consultant, it is my ‘value-add’ that I provide my clients. I build my internal body of knowledge and as I leave the team I show the team the knowledge I am leaving them.

Invite Others to Join In

Once you have the knowledge base started and others can see the value, invite them to add their knowledge to yours. This can grow the knowledge exponentially. Obtaining their buy-in is much easier when you can show them the value.

Get Started

So now you know what an internal business analysis body of knowledge is and have a concept of how to build one…get started. Determine who you wish the knowledge base to serve, determine where to store it and get started building it.

By building an internal business analysis body of knowledge for a team or organization that you will eventually leave; face it we all leave at some point whether by choice, retirement or other forces, you can leave behind business, systems and tacit knowledge you have built up over time. The great advantage of starting early is that you don’t have to hurry up, remember everything and build it all in a short timespan as you prepare to leave the team. For a consultant leaving a team, this is a great ‘value-add’ to provide for your clients.

Don’t forget to leave your comments below.

Initiating ITIL Implementation in a Small Organization

Written by Shriram Divakar on May 26, 2014. Posted in Articles.

Understanding the need for improving the process and what exactly the organization is trying to address is very important before we plan to apply any framework to an existing system. ITIL address many critical issues faced by any IT industry (small/large). Let us consider the below aspects,

Service downtime that the business tolerate
SLA /acceptable recovery time
Creating customer value from a service industry perspective
Running an integrated help desk
Reducing IT Operational Costs
Improve availability
Optimization of resource Utilization

Considering the above benefits, it truly does not matter if it’s a large or a small organization, it’s very lucrative and we definitely get a lot of advantages by implementing ITIL framework.
I will try and capsule my ideas of implementing ITIL (specific to Small organizations) and document in a very simple and understandable format. This is purely from my perspective; I have implemented and it served and worked effectively in reality.

Depending upon the industry (service or product), ITIL implementation can be initiated by conducting the discussion between the business and engineering. Outcome of the discussion can be multiple action items and the most important will be the agreed SLA.
Second and very important step will be to form a strong team of resources which understands each and every issue/requirements from both functional and technical standpoint. We can name the team as the control team and will be the approving authority for any change to the existing system.
ITIL has a lot of process and it is very tough to implement all of them right from the word go. I feel, it’s a good practice to start with Incident Management, Problem Management, Knowledge management, change control management and release management and setup the process, expectation and teams accordingly.
Implementing the above 5 process and meeting the SLA will give the results which will address the important ROI’s like service downtime that the business tolerate, acceptable recovery time, running an integrated help desk, reducing IT Operational Costs, Improve availability.
Assign process owners/leads.

The flow can be as below,

Strong Help desk team which will record the incident and check for available solutions in the KMDB or raise a problem ticket, assign and follow up.
Effective Problem management/production support team which will work on the solutions and request for change.
As mentioned before, control team which will analyze the change and approve. (Post approval–Close problem management)
A hands on release team to deploy the changes (Post deployment–Close change Management)
Incident Management/Help Desk to confirm the successful change and update the KMDB accordingly (Post confirmation–Close Incident Management)

There are many other aspects which will be controlled by implementing the above process. The control team can make sure of approving the required and correct CMR (change management requests) by which we can control and minimize the after change errors which is the main cause of production outages.

Some of the other key processes are capacity management, availability management, information security, risk management, configuration management, asset management, event management, access management and each process has their own benefits. We can initiate, implement and sustain with these 5 processes first and once successful, we can try and sneak the other process one by one and will fall in place.

What organization doesn’t want an increase in productivity? Or is there an organization that does not entertain cost and operational benefits. We can always customize the framework and implement process to meet our needs.

Don’t forget to leave your comments below.

Sprint Reviews – Learning’s from the Movies

Written by Robert Galen on May 19, 2014. Posted in Articles.

My wife and I saw two movies over the holidays. One was The Hobbit: The Desolation of Smaug and the second was The Hunger Games: Catching Fire. Both were the second episodes in a three part series. I suspect both were shot at the same time as their concluding episodes as well.

No, this is not a movie review, although both of them were “reasonable” follow-ups to their opening episodes. But both also had a similarity—one that bugged both my wife and I very much.

Both of them left you (the audience, the customer) hanging at the end. And I’m not talking about a subtle ending that hinted at a future plot direction. I’m talking about an abrupt, no warning at all, CUT off of the movie in lieu of the next (and hopefully final) installment.

It was so abrupt that it was painful and it tainted our impressions of the overall movies. In fact, that’s all we’ve been talking about afterwards. Not so much the positives or the things we enjoyed, but how rude the ending was. How blatantly it disregarded the experience of the audience in order to tack on another episode.

But enough about that. Yes, we were unhappy, but that’s not the point of this article. It struck me that many sprint reviews are like these movies and I want to explore some things to consider for your sprint reviews or demo’s. Call it lessons learned or inspired from these two movies and movies in general.

Here are 5 things to consider when you’re executing your Sprints and planning your Demo’s:

Tell a Story

Some of the most challenging demos are where the team insists on showing everything they’ve done in the sprint AND where the work is disparate and not well connected. I’d much rather the team tell a cohesive story with their efforts for the sprint and tie it to their sprint goal. Another part of story telling is sharing the “behind the scenes” challenges and efforts. For example, how did you plan, what got in your way, how did the team swarm around the work, and how was adversity met – are all questions I might have. I’m often interested in the teamwork and trade-offs as I am in the results themselves.

Practice

I’m sure in most movies the actors don’t just “dive in” and make up their scenes and the dialogue as they go. There are storyboards, planning, and of course, the script. All go into the practice and preparation to make the story unfold in a smooth fashion. I’m not suggesting that any agile team needlessly prepare for the sprint demo, but they should be ready. Have a “script” and do a dry run if you need to. Make sure your audience experiences a strong and thoughtful demo versus your unpreparedness.

Focus on What’s Important

I’ve often heard folks complain that a movie didn’t exactly follow the book. That much of the story had been modified or cut out. I often think to myself what a move would look like if the scripts exactly followed the book. How long and how boring would it be? I think movie adaptations for books must focus on the important threads of a story. Themes matter, priority matters, and you have to be comfortable with trimming things down to their essence via “just enough” and “just in time” thinking.

Connect the Dots – Coming Attractions

One of my “pet peeves” for sprint demo’s is that they need to avoid stand-alone deliver. I like it when they connect the results in the current sprint to past AND future deliverables. Aligning with whatever release plans, roadmaps, or strategy your organization has. Another part of connecting the dots is talking about look ahead, as it relates to architecture, design, dependencies, and integrated testing. Show attendees that you’re not only delivering in the small (sprint), but that you have the “big picture” in mind.

Endings Matter

And back to my two latest movies, please realize that endings matter. You want to leave your audience fully understanding what you’ve delivered and the “big hairy business why” behind it. And you want to tease then with the future by connecting the dots forward. BUT, you want to do it with thoughtfulness and subtlety. Provide insufficient connection, and they won’t know what’s next. So they might not come to your next “performance”. But do it too heavy handed, and they might forget everything else but the hard sell at the end.

And here’s something I like to do in my Sprint Demo’s that movies can’t really do. I like to gain immediate feedback from the audience. You might try the Fist-of-Five as a quick technique to see how everyone feels about the show 😉

Wrapping Up

I continue to be amazed by the soundness of basic agile principles, ceremonies and tactics. That something as simple as a Sprint Review or Demo has so much variability in it – from doing it poorly to doing it incredibly well.

This is where the team comes into play in collaborating around and planning high-impact sprint reviews. One of the biggest mistakes a team can make is falling into a tempo of doing the same old, by-rote sprint reviews. And then wondering why attendees are falling asleep or missing in action.

Consider each Demo to be a unique presentation or movie. Give it its due and consider the above when crafting each performance. Your customers will appreciate you for it.

Stay agile my friends,
Bob.

BTW: here’s a link to a more thorough discussions I’ve had on Sprint Reviews or Demo’s:

Slide deck
Webinar
Blog post

all are somewhat interrelated

Don’t forget to leave your comments below.

Continuous Quality Management of Software Applications

Written by Mugdha Divekar on May 19, 2014. Posted in Articles. 1 Comment on Continuous Quality Management of Software Applications

Today’s software applications are fundamentally different in nature as compared to what we have seen them till very recently. It is primarily in terms of how they are being developed, their complex architecture, variety of usage by end users, varying needs of users from the applications and its ability to sustain to big data needs. So it is of paramount importance that the applications are envisaged rightly for these needs and are ensured that it is getting rightly built throughout the life cycle phases of the same i.e. conceptualize to deployment. Continuous Application Quality Management (CAQM) is simple approach that will help all the software application teams to join hands and ensure the right application with right quality is delivered thought the life cycles. The testing team OR quality assurance team can play extremely important role in the same by providing right orchestration and collaboration of various independent teams of software development like BA, designer, architects, user experience team, QA, developers and many others. This article reveals the CAQM approach with some relevant tips and tricks of how to go about it.

CAQM is extremely powerful approach to ensure critical to quality requirements are gathered from right stakeholders and they are implemented well in an application.

What is “continuous application quality management i.e. CAQM”?

Every individual software system/application possesses unique set of quality requirements which are critical to that application. These quality requirements can be from functional perspective OR non-functional aspect as well. Most of the software projects pay attention to these quality requirements only at the time of system testing or performance testing. That is a reason that many a times software system which is functionally excellent fails to cater to the need of users as no one paid enough attention to these “critical to quality requirements” when the system was getting built. Even if there is adequate focus on to test these requirements during testing phase, it might be too late and too costly to fix the issues as cost of fixing a defect rises exponentially with each LC stage.

CAQM suggest that there should be focus on “critical to quality requirements” right from the beginning by various stakeholders involved in the application development. It also ensures that these parameters are monitored, measured through-out the life cycle of an application and corrective OR preventive actions are implemented at right time to get the application health on track.

Let me explain this concept with a simple day to day example. With this example, it would be very easy for you to relate the scenario with software application as well. Let’s say I have a mission in hand that in next 6 months I need to clear certain medical test of military entrance exams which has very stringent requirements on my health parameters. So first thing I will do is understand the “critical to quality” requirements of this entrance test i.e. the requirements in terms of health parameters like height, weight, BP, blood sugar levels, thyroid, B12 levels, vision etc. which will help me clear the test if they are in the best possible range. So I will identify the key parameters and its values that I should be attaining after 6 months. I visit my family doctor and discuss this. As he knows my medical history, he suggests 2 more parameters to track as they impact the thyroid levels. Then I conduct all the medical tests and measure the parameters. I create a plan like below in consultation with my doctor so as to reach to the target value of parameters. I also decide the frequency in which I need to measure the parameters on ongoing basis till the entrance exam date. So I create health assessment dashboard for all the parameters that are critical for me to be exactly same or better as that of target values like the one below. I have given it for couple of parameters and couple of intervals. But I need to maintain it for all parameters throughout the journey.

I can also track all my parameters on a spider chart graph as shown in the diagram. It helps to get a quick understanding of where exactly I stand today and where do I need to reach.

So as I have started right with identifying right health parameters, their expected target values, by consulting SMEs to understand what more should be focused. Then I am taking a stock of where am I on start of the journey so that I know how much ground is to be covered. I take necessary efforts and actions and measure the parameters on regular small intervals and take necessary course correction so as to ensure that I will achieve my targets. So with this approach likelihood of me clearing my military entrance test is more as compared to what I would have normally done. Normally one may not have gone with so much of a methodic approach and ensure regular frequency check -ups and possibly would have just checked the values before entrance tests. In such case, chances of me not clearing the tests are more as I have simply left it to my luck factor.

So essential take away from this approach is

Gather right requirements/parameters that are critical for our mission
Reach out to right set of stakeholders to understand these requirements from their perspective
Set target values to these parameters so that the final outcome will be the best
Periodically measure the values/health of the project
Consult subject matter experts to take corrective/preventive actions at that stage only instead of making it very late in the cycle
Implement action items and check its effectiveness in next interval results. If not effective, re-plan the same.

A very similar analogy can be drawn for software quality as well. Traditionally, for better software quality we just rely on system testing and performance testing just towards the end of life cycle and if something drastically wrong is found, it is almost impossible to go back and correct the same. We will still correct something and release application to production. But people may not use it because it is not serving the “critical to quality” needs of an end user.
Hence I will recommend the CAQM approach to address this issue and ensure right software is built and delivered.

CAQM is based on ISO 9126 concepts which define “Critical to Quality” requirements of any software. ISO 9126 defines various software characteristics like functionality, reliability etc. For each of the characteristics there are sub-characteristics associated like maturity and fault tolerance are sub-characteristics of reliability. For each of the sub-characteristics there are multiple metrics that can help evaluate that particular aspect of the same. One such sample metric is given below

TurnAround time is a metric defined under efficiency characteristics and time behavior sub-characteristic.
Definition: – What is the wait time the user experiences after issuing an instruction to start a group of related tasks and.
Formula: – T = Time at which user finished getting output results – time at which user finished placing request

A quick summary of ISO 9126 characteristics and sub-characteristics is given below for reference.

But in case if your applications CTQ requirements are something other than the one mentioned in ISO 9126 model, you can include them for your application and track them.

How to implement CAQM in software development?

The below section depicts how CAQM can be implemented in a software project.

Key success criteria

The key success criteria for implementing this approach is –

Collaborative approach – Typically the activities in CAQM demand that they need to be done in a collaborative fashion having various teams involved in as mentioned above. Every team needs to have a single vision i.e. best quality of application in optimal time to market and cost. They should be extremely open and flexible to accept the issues and problems that have occurred due to their contribution in the SDLC and should be ready to rework on it even if indicated by some other team.
Customer willing ness to invest extra– As these are some additional activities that are suggested on and above the basic SDLC phases activities, there should be willingness by client to spend extra money on the effort and time needed to perform these activities. The expected ROI on these investments is huge as compared to the investment made.
No cuts on any of the standard technical reviews of process artifacts at various life cycle stages – The approach suggested in CAQM is over and above the traditional life cycle appraisal and prevention activities. This does not recommend any cuts in the reviews/testing etc. which is part of the life cycle phases.

In absence of any one of the points below, the overall approach for CAQM will not be effective.

Conclusion

CAQM is an approach using which there can be constant focus on key health parameters of the application. Application health is monitored in multiple logical intervals and corrective/preventive actions can be taken up at right point in time.

This needs a collaborative approach for successful implementation. Though primarily it is based on ISO 9126 model, we can have any other critical to quality attributes which are specific to the application or client context. CAQM can be achieved in simple spreadsheet based tools that we can create to capture, track and create trend analysis of the data. If done in a right way and right spirit, it helps achieving great results in terms of application quality, productivity, cost and time to market.

References
1. ISO 9126 model