As many of you know, I'm passionate about Business Analysis and Business Improvement, and I love speaking and presenting on these topics. I am shortly departing for a trip to the US, and whilst I'm there I am speaking at a number of IIBA chapter events. The details are shown below - if you happen to be in the area at the time, it would be great if you could come to one of the events.

I'll be presenting on two topics : Firstly,  Stakeholder Engagement and Management and how it's possible to ensure the right people are involved at the right times during projects.  Secondly I'll be exploring the expanding BA role including how to sell the role to executive stakeholders.

I'm thoroughly looking forward to my trip.  See you there?

Adrian 

Adrian's speaking itinerary - August 2011

3 August @ 17:30 -  New York City

Making a difference in projects - the expanding BA role 

Microsoft, 1290 Avenue of Americas, 6th Floor, New York, NY 10010-3602

4 August @ 17:30 -  Iselin, New Jersey

Stakeholder Engagement: Delivering Projects in the Face of Adversity 

Microsoft, 101 Wood Avenue South, Iselin, NJ

9 August 2011 @ 18:00 -  Baltimore 

Stakeholder Engagement: Delivering Projects in the Face of Adversity

UMBC Technology Center:1450 South Rolling Road, Baltimore, MD 21227

10 August 2011 @ 18:30 - Washington DC

Making a difference in projects - the expanding BA role

The Graduate School, 600 Maryland Avenue s.w.Washington, D.C. 20024

Topic 1: Making a difference in change projects : The expanding BA role

The Business Analyst role is changing.  BAs are increasingly being recognised as professional change practitioners who can add value throughout the entire project lifecycle.  However, the extent of this development varies by organisation.  In some organisations, Business Analysts have much broader remits than others and there is still no single definition of “Business Analyst” or “Business Analysis”

In this presentation, Adrian Reed will outline the changes in the role he has observed in his role as a Lead Business Analyst in the UK.  He will discuss the “core business analysis role”, along with the opportunities and challenges that are facing the international BA community, including:

• The changing breadth and depth of the BA role, as observed by a UK based practitioner
• The different pressures that organisations are facing, and how BAs can add value
• The need for the BA role to be understood by senior stakeholders within organisations
• Ideas for “selling” the BA role to stakeholders throughout the organisation, to encourage early BA engagement.
• Hints and tips for increasing credibility amongst senior stakeholders

In this interactive session, Adrian will outline his observations from the UK, and will invite discussion from the audience to compare and contrast with how the BA role is perceived in the US.

Topic 2: Stakeholder Engagement : Delivering projects in the face of adversity

“Projects don’t deliver change.  People do”.

People are a key part of any change project.  Therefore, successfully engaging and managing the right stakeholders is an essential activity on any project.  In large projects, there may be a diverse and dispersed group of stakeholders, all of whom have an interest in the end deliverable.  It can be difficult to know who to engage when, and the consequences of getting this wrong can be painful!

In this presentation, Adrian Reed (A UK Based Business Analyst) will discuss how to identify, categorise, engage and manage the stakeholders in a project.  He will discuss:

• How to determine which stakeholders really matter on your project
• What to do if a key stakeholder isn’t taking enough interest in your project
• The best ways of analysing the needs of your stakeholders
• Tips for communication styles and building rapport
• Tips for leading and engaging a team that is spread across diverse geographic locations
• Tips for engaging and approaching executive stakeholders who you haven’t worked with before
• How to handle conflict if it all goes wrong!

This practical and memorable session will be useful to Business Analysts, Systems Analysts and anyone who has day-to-day involvements with IT or change projects.

As experienced change practitioners, I’m sure we’ve all worked on projects that have been difficult.  The unfortunate truth is that some projects gain so much momentum, they become “too big to fail”.  These projects steamroll their way through organisations, and have a tendency to displace anyone that dares to challenge them.

Sometimes when working closely on a project, it is difficult to see the warning signs.  However, it is worth carrying out a project “health check” every now and then, to check for danger signs.  If you see any significant warning signals, then you might need to take some serious (and unpopular) corrective action.  Five such signals are discussed below:

1. Experts are ignored:

Projects that are in trouble may choose to selectively ignore concerns raised by experts.  Inconvenient truths tend to be “parked” or “explained away” without further analysis. Even worse, the commitment of those raising the concerns may be questioned.  This tends to have an extremely negative effect – morale of the project team is likely to suffer as they don’t feel listened to.  And even worse, they may feel disinclined to raise concerns in the future.

Organisational solution: Organisations and projects should encourage their experts to speak up.  It is generally better to know the “cold hard facts”, and every member of the project team should be encouraged to share their constructive concerns. This issue will cease if an organisation proactively fosters accountability, whilst also fostering a culture of continuous improvement and learning. And remember: A project maverick is not a heretic!

2. Business cases are “re-worked”:

Business cases should be a central tool used by organisations to ensure that only profitable projects are run.  In some cases, other “hidden agendas” may be at play, and the project team might be asked to use some “creative licence” to make a business case look profitable.   This often happens in organisations where there is little accountability for the realization of project benefits.

Organisational solution: Organisations can stop this happening by encouraging and valuing true accountability, from project sponsor downwards.  The sponsor should be accountable for the delivery of benefits as well as the delivery of the project. Each project team member should be empowered to challenge decisions which seem to contradict the business case or scope.  Empowerment, accountability and integrity are the three key values that will prevent this situation from occurring in the first place.

3. Unclear objectives or scope:

One of the most serious warning signs on a project is a lack of scope.  If you start work on a project, and scope or objectives are not clear, then you are in for a rough ride.  This suggests that there has not been adequate attention paid to the foundations of the project, and in most cases it will be beneficial to step back and agree the scope.  If this doesn’t happen, there is a significant danger that the solution will be delivered in a way that does not meet expectations, and does not maximize return on investment.

Organisational solution: If scope or objectives are unclear, the only way to address this is to firm them up.  Good governance should stop this happening in the first place, but a project has slipped through then the project team should work to reach a consensus, and then move forward.  This might cost time in the short term, but it will save significant time in the long term, as it reduces the risk of misunderstandings and miscommunication over scope.

4. “Risks and issues” only exist on a log:

Embedding risk management techniques leads to more successful projects.  A significant project warning sign is RAID (risk, issue, assumption, dependency) logs that have not been maintained and are not being followed up.  This suggests that risk management is happening only “On paper”.   Each risk should be owned, and should have a defined strategy for dealing with it.  If this isn’t the case, then corrective action should be taken.

Organisational solution: The only solution to this problem is to ensure the project manager is actively controlling risks, issues, assumptions and dependencies.  If they are not, organisations should encourage and compel them to do so!

5. The project schedule doesn’t exist or is out of date:

A project and programme schedule should be a central communications tool.  Ultimately, this is a central tool that ensures everyone knows what tasks they need to complete, and what the deadline is.  A great way of carrying out a health-check on a project is to ask a random member of the project team where the project schedule is located, and ask them to show you a copy.  If they can’t, or if it is out of date, then you have uncovered a communication problem.

Organisational solution: Good governance and project discipline should ensure that all projects have a schedule that is fit-for-purpose.  Ask questions to ensure that a schedule is in place, and if it is absent then ensure it is created as soon as possible!

Conclusion

I see these warning signs as the “Big 5”, though there are many others that may surface on a project, and as change practitioners it’s important for us to recognise them and take any necessary corrective action.  Unfortunately, the corrective action is rarely palatable.  The most important thing we can do is to constructively challenge ourselves and our project colleagues, and ensure they are dealing with the cold hard facts.  We should escalate where necessary, and ensure that facts are not hidden and experts are not ignored.

Positive and proactive challenge and escalation is rarely popular, but is necessary to ensure that organisations get the best from their projects.  Good luck!

Have you worked on projects and seen these (or any other) warning signs?  Do you have any further examples?  I’d love to hear from you – feel free to contact me directly or leave a comment below.

Asking the right questions and framing problems carefully is an important part of project definition and organisational change.  Often organisations frame problems in a way which constricts or constrains potential solutions, and this can lead to a poor outcome or the wrong tactics being employed. Spending time consciously defining a problem can pay dividends in the long run and can increase the likelihood of successful change.

Take a theoretical example: Many companies conduct staff engagement or satisfaction surveys. These surveys are designed to measure how engaged, satisfied or motivated their employees are. If an organisation has “bad” results on its staff survey, leaders and managers are likely to want corrective action to be taken. After all, nobody wants unmotivated employees.

The first step to addressing the issue is to define and frame the problem. Often this framing process happens unconsciously, but it is significant as it impacts the way that people interpret and respond to it.

The two questions below are ways of framing the problem described above. These two questions look similar on the surface, but they are actually incredibly different:

1. “How can we improve the staff survey results?”

2. “How can we make this a great place to work?”

In my experience, organisations ask question 1, which focuses on the symptoms. In the staff survey example above this might involve identifying key themes, and perhaps corporate communication is one of them. The organisation responds by starting newsletters, having “open door management” policies, but the culture doesn’t really change.  The executive team look at the metrics “How can we move from 10% on the satisfaction scale to 15%?”. They apply palliative measures, and the root cause is never even investigated, let alone resolved. The objective becomes about improving the figures not improving the organisation.

Organisations really need to ask question 2.  They need to investigate the systemic cause of the issue – accepting that the symptoms might only be the tip of the iceberg. This might require a change in the organisational culture and will certainly require observing the organisation as a complete system. Question 2 opens a can of worms. It requires stepping back from the metrics, and that’s an uncomfortable thing to do.

This is just one (albeit complex) example.  Problems are defined and framed every day in organisations – perhaps in an operational context, or perhaps in a project context.  Thoughtful and robust problem definition and framing change the way people think about the problem, and open up new solutions.  As Business Analysts, we should encourage and facilitate this kind of thinking – asking challenging questions can be incredibly valuable!

How do you go about defining and framing problems?  I’d love to hear from you- please feel free to contact me directly or add a comment to this post.

The Praganalysis team (Joe da Silva, Phil Bailey and Adrian Reed) are pleased to are pleased to announce details of their new project – a completely free requirements management tool.

We’re conscious that we’ve been a little bit quiet recently, and we wanted to take this opportunity to provide you with some information on our current project. We’re extremely excited to announce that we will be releasing a completely free requirements management tool.

We’ve probably all worked on projects where the capturing, prioritising, tracing and managing of requirements becomes difficult.  With a plethora of Word, Excel and Visio diagrams, version control becomes difficult and there is a danger that different stakeholders may be referring to different versions of documents.  In addition, a traditional template based can make it difficult to capture all the necessary requirement attributes, and in particular creating sustainable links between requirements and artefacts can be difficult.

There are many commercial requirements management tools on the market, but all of these cost money.  We have set ourselves the challenge of creating a new tool designed for BAs by BAs.

More information will follow in the coming weeks and months, but our vision is to create a requirements management tool that:

• Methodology neutral: Whether you use Scrum, Waterfall, DSDM or Kanban, our vision is that the requirements tool will add value.
• Intuitive: The tool will be intuitive, and easy to use.  It will be supported by online help where necessary.
• One-button reports: A variety of reports will be available.  It will be possible to create a dashboard report at the touch of a button.
• Requirement capture: Requirements will be held in a database, along with requirement attributes such as source, owner, priority.  It will be possible to link to other artefacts (e.g. Visio diagrams) where necessary.
• Requirements groups: It will be possible to assign requirements to “groups”.  Perhaps you might want to sort requirements by release, iteration, or even by a functional split.  Requirements groups will allow you to do this, and will allow you to report on each group separately.
• Requirements Catalogue Report: It will be possible to export the requirements catalogue as a standalone file, so it can be circulated to stakeholders for review.
• Risks, Issues, Assumptions, Constraints, Dependencies: It will be possible to log and track issues and risks.
• Linkages: The tool will allow linkages to easily be created between items, so that impact of change can be assessed.

Most importantly, the tool will be completely free.  We’re incredibly excited about this project, and we hope you are too. 

Watch this space for more information!