10 and 1/2 commandments of visual thinking

Changethis is a website that publishes articles in PDF format each moth. They are on a very wide range of issues.

I want to bring your attention to this particular article from March. It's called the 10 1/2 Commandements of Viual Thinking. It's relevant to you because it has some great insight into how diagrams can solve the world's problems.

It even highlights the six most versatile ones (that's right, you'll never need another one again.)

So for beginners it starts to set up a framework and for experts it brings you back to basics. I hope you like it.

Read the article here:

• 10 1/2 Commandements of Viual Thinking

Presentation tips

From Rowan Manahan of Fortify Your Oasis.

A challenge for detailed oriented project people is how to convey complex messages with simplicity. Maybe this will give you some ideas .

View Upload your own

Project Management
Business Analyst

Requirements Communications & Management

The BABOK bundles Requirements Communication together with Requirements Management. I see them as two distinctive processes, and so after my brainstorming ideas on requirements communication I am now going to run through some ideas on requirements management.

I am very interested in the thoughts of project managers and Analysts who are reading this on where I am on the money and where I am missing key points. So – if you are persevering with these posts, do your bit and comment!

(The content on requirements management will be shorter than the BA Communications posts, I promise.)

Project Management
Business Analyst

BA Communications - context

(Click on image for a larger view)

This diagram considers the context of a business analyst and looks at the flow of their communications.

The arrows point in only one direction, which suggests who initiates the communications, nothow the communication flows in total. In fact most of the data should flow in towards the BA, who then analyses and interprets it.

BAs have a responsibility to both the Project Manager and the Sponsor. This can lead to conflict, especially when the BA is not privy to prioritisation discussions on cost, scope, time and quality. It can however be an opportunity to keep the PM honest and the Sponsor engaged.

BAs communicate to “I.T.” and to “The Business”. (My preferred language for this is that BAs communicate with both the solutions team and to the stakeholder and user groups.) The BA, like the PM is a communications hub for projects. This highlights two key points; make sure your communications are planned so that it can be as effective as possible, and make sure your messages are aligned with the PM.

BAs also communicate with QA, which can be both proactive QA processes and testing. Good quality management processes start early and the BA involvement in these should as well. Communication between QA and the BA is a fantastic opportunity to reduce risk, time and cost for projects.

Communications may be direct or via proxies. The effect of sending a message via a third party dilutes the effectiveness of communication. As a result, if your messages are going to be delivered by others you need to manage this dilution.

Conflicting or ambiguous messages may be transmitted, competing with the BA’s messages. If the PM sends out one message and the BA is sending out another message the receivers will be challenged to find the right meaning. Additionally the BA and PM need to be aligned in messages in order to ensure the appropriate socio/political agendas are managed.

Different messages have different priorities with the receiver. For example, a senior user will usually prioritise a message from the sponsor over a message from the BA or project team.

Project Management
Business Analyst

BA Communications - the risk factors

The next dimension I want to have a look at BA communications from is risk.

If we wanted to place a generic risk onto the risk register it might go like this:

There is a risk that the BA may be ineffectual in their communication activities across the project resulting in:

• A poor understanding of the requirements by the solutions team,
• Misunderstandings and inappropriate expectations from stakeholders and user groups,
• A misalignment in vision about the project within the project team,
• Politics overcoming rational decision making in relation to the project and
• The project failing to meet it’s objectives.

The impact of this risk, if it were to eventuate is devastating for the project, and those involved in it. The likelihood of this risk is up to you, the analyst on the project.

Drilling into this further we can identify key risk areas that you can be aware of in order to minimise this risk to your project.

Firstly, know your team mates. As the Business analyst your team mates sit in both the business environment and in the solutions space. You need to get to know them so that you can most effectively communicate with them.

A shared or mutually understood culture fills in a lot of gaps that otherwise present opportunities for misunderstanding. Knowing them helps you understand them and align the way you communicate to their needs and expectations.

Secondly, make sure you get some face to face time with everyone you interact with. We’ve heard about the increasing degrees of efficiency in communication as you scale up from written to face to face communications. (If you haven’t, read this.)

Seeing someone face to face also brings you closer together as people. You are more likely to be positive in your interactions in the future.

Next, ask people what they expect from you in your role, to help clarify everybody’s expectations. Maybe follow this up with a presentation on your role in the team and how you’ll be contributing.

There are a couple of proactive management activities you should also undertake when planning your communications. Obviously I’ll encourage you to create a written plan and share it with your PM, who should integrate it into their Project Communications Plan. To do this effectively you should identify who will be stakeholders, decision makers and reviewers to the documents and artefacts you create and manage through the project process. The same goes for the end product your project team is creating.

So stakeholder analysis is a key part of BA communications activities.

And one of the steps in a stakeholder analysis for your communications plan is to understand the best mediums, frequencies and triggers for communications.

Project Management
Business Analyst

Picture by Splorp at Flickr

BA Communications - a (draft) conceptual framework

(Click the image to get a larger view.)

This diagram helps illustrate my views on the relationship between BABOK Knowledge areas (and BA work activities) and BA communications.

Remember this is just me thinking out loud before I review the BABOK (2.0) draft chapter on Requirments Management Communication chapter. I'm postring up some greenfields thoughts before I start looking at the content so I can assess completeness, as well as accuracy of the content.

Your feedback is most welcome.

Project Management
Business Analyst

BA Communcaitions - The Benefits of Good Communications

What are we expecting to achieve through a disciplined and proactive approach to communications?

The primary roles of BOKs seems to me to be to;

(a) increase practitioner effectiveness in delivering successful projects and

(b) create a common language to enable practitioners to move from company to company –standardising the environment so your skills are more useful in more places.

The first objective is clearly stated and promoted, the second less so, and probably declines as a visible objective over time until it becomes implicit rather than explicit. So a BA Communications Knowledge area should be focused on these two dimensions; Increasing practitioner effectiveness and creating a common language

Increasing practitioner effectiveness

• Know expected outcomes from communications activities
• Know the accepted practice for what to communicate, to whom, when, how and why
• Know typical traps in communications and how to avid them
• Map communications activities to overall work activities to provide context

Creating a common language

• Defining and explaining key terms
• Providing templates for messages

Know expected outcomes from communications activities
The key outcomes for a BA are successful implementation of a system, process or other project outcome that enables the flow of business cased benefits.

Along the way there are more incremental outcomes such as consensus on the business problem or opportunity, on the right solution approach, on the details of the solution, on it’s implementation and how it will be actually used.

There are also some optional outcomes depending on the project type; such as agreement on how the solution will be validated, how it will be rolled out to user groups and so on.
Lastly there is the provision of subject matter expertise to the various people who need it, particularly the solutions team as the construct the actual solution.

Map communications activities to overall work activities to provide context
There is room in a BOK to provide a table of required and optional communications activities mapped against generic project lifecycles. There may be a tendency to focus on SDLCs but it might be a better idea to look at communications activities mapped against the BABOK knowledge areas.

I’Il come back to this topic a little later in this discussion. Feel free to throw me your ideas in the comments.

Know the accepted practice for what to communicate, to whom, when, how and why
This step involved taking your communications map of the process you are following and overlaying it with the people you are going to communicate with, and highlighting the key messages and issues you will face when communicating to them.

It might also describe the format of communications, and the cycle or triggers for communications events.

It could also elaborate on the reasons why these are described as good practice, as there is a significant body of knowledge in communications anyway.

Know typical traps in communications and how to avoid them.
Each project is unique but personality types seem to be recurring. Some modelling to highlight risk areas for communications and strategies for dealing with these risks might be useful.

Tips might include; Stakeholder Analysis, Complexity Analysis, ascribing default modes to different organisation types (such as formal and informal), etc. (A CYA section may be useful.)

Defining and explaining key terms
This can be an outcome, but it’s also a task. The outcome is that you have a language that is as clear as possible across your project community, and that you have a language that you can use when travelling across companies and industries.

One we are speaking the same language we are able to more quicly come to the issues and address them.

Providing templates for messages
Templates would be a great resource, especially for new practitioners, as they provide a checklist of things to consider when publishing documents or sending out messages.

The disadvantage of templates is that it encourages the lazy practice of filling out forms without considering the content.

So maybe I am not sure of the appropriateness of templates. What do you think?

Project Management
Business Analyst

Picture by Splorp at Flickr

BA Communications - Considering PM Communications

Carrying forward our discussion from yesterday around BA communications, another point to remember is that the BA communications plan and work should be able to be imported into the PM’s Project Communications Plan.

Saying that, the next area to reflect upon is the relationship between the project manager’s communication management activities and those of the BA.

The PMBOK highlights 4 key processes also;

1. Project Communications Planning
2. Information Distribution
3. Performance reporting
4. Manage Stakeholders

The BABOK is aiming to be a BOK of things specific to the BA role, but communications is so ephemeral and integrated into all project work it’s hard to distinguish it? What differentiates the BA Communications knowledge area from the PM Communications Management knowledge area?

I would say the main difference is in the focus and the level of attention paid to the details of the communications activity. A PM’s communications plan may identify that a Requirements Specification will be published, reviewed and approved, while the BA, who is managing the specific activities may also include in his or her plan the activities of scheduling walkthroughs of the document, booking meetings to discuss the contents, managing a log for feedback from reviews and so on.

This doesn’t seem to me to be a differentiator of any significance since differences in detail are relevant to size and scope of a project, to the organisational culture and PM style.

Maybe I’ll come back to this topic after I look at the desired outcomes for a BA communications KA.

Project Management
Business Analyst

BA Communications - Why its important

The purpose of calling out Communications as a BA knowledge area might seem obvious, but it hasn’t always been so, and still isn’t to everybody.

Basically the BA’s main role on projects is to manage the ‘business requirements’ through the project lifecycle. The BA acts as a, or on behalf of, a product owner. They are accountable for the articulation of the business problem or opportunity and have a strong voice in the solution strategy and design.

Business analysts also have an active interest in successful benefits extraction from the project, and are active in communicating to key stakeholders to projects, particularly subject matter experts who have a say in the product requirements & constraints, and also user groups who are the end users, or beneficiaries, of the system

The BABOK approaches BA knowledge areas and work activities with a requirements management perspective and so it labels the BA Communications Management work as Requirements Communications.

In fact BAs do involve themselves in more than just requirements. Invested in the business outcomes they are also active in change management and business process design. A tool without a context adds no value, but once you motivate people to use it, and show them how and when it’s appropriate to use it, the benefits start to flow.

So for me BA communications go beyond requirements and into process design and change management.

In fact the BABOK aims to be methodology agnostic, and so it’s framework should be appropriate for process improvement projects as well as IT systems developments. In that context the emphasis of communications sits squarely on process design and change management.

So the key areas for BA Communications are;

1. Requirements communications
2. Process design communications
3. Change management communications
4. Stakeholder management communications

I guess you could raise an argument that process design is integrated into requirements management, but my view is that it sits in the solution domain, and so is different.

Also, what’s the difference between Change Management and Stakeholder Management?
Well, stakeholders don’t necessarily need to change, but users do, and helping them through the process helps drive those benefits. Stakeholders on the other hand can cause roadblocks and barriers to benefits extraction, so you need to keep them onside, and communication seems to be the best way to facilitate this.

So, unless you care to challenge me on this I am putting these points down as the four main pillars of a BA communications framework.

Project Management
Business Analyst

Picture by Splorp at Flickr

The Trust Requirement

Intelligent dialogues require trustful relationships.

In the previous post "Most Requirements are just Design Decisions", we invited BAs to rethink the rigidity of software requirements.

Relevant environmental changes or new knowledge should trigger corresponding requirements adaptation. Leading this process, a BA adds more business value to their organisations.

Unfortunately, requirements are just requirements for many BAs. They don´t have the opportunity to participate in the intelligent dialogues where strategic design decisions are made.

Effective collaboration between the IT function and other business functions can be a complex and difficult issue in many organisations. This represents a critical credibility problem that must be addressed both by IT executives and IT professionals.

The perceived credibility of an IT professional goes beyond his or her personal competence and integrity; it is grounded in trustful relationships.

Principles

Now I invite you to reflect on your professional relationship style. Is it effective to create and nurture trustful relationships? Here are some principles I have used over the years with good results.

Be a Good Citizen at Workplace. Genuine citizenship behaviour means to me to actively respect all fellow professionals and executives and foster a positive, constructive and productive work climate.

It is also important to have a clear view of what is bad workplace behaviour. David Maister highlights "20 bad workplace habits" from Marshall Goldsmith´s book "What Got You Here Won’t Get You There".

Reach Out and Touch. Try to see where you and your clients fit in the whole picture. Be open to learn, understand and appreciate their values, interests and the language they use. Then, get closer to them.

Promote Dialogue and Empowerment. I found myself many times eager to present solutions to users as soon as I grasped the most salient problem issues. I learned through experience that rich and frequent dialogues are key elements for more fun and effective processes, that generate better quality solutions and results.

Give Consistent Care. Respond quickly, reliably and honestly to your clients demands. Make sure you consider thoroughly how all your actions will affect their actions. Always be in the front with your clients during major software transitions.

Do these principles resonate to you?

Share with us your thinking about this critical issue for our profession.

I thank Raven Young for indicating David Maister´s post, that inspired me for this post.

Picture by Think Panama's photo stream.

Original at Flickr.

Project Management
Business Analyst

BA Communications - intro

An important aspect to the role of the business analyst is communicating.

It’s a moot point that effective communication is critical to project success. That includes communication across the team, into the team from third parties and out from the team to stakeholders, the client, suppliers and others. Without effective communication things break down quickly.

If projects are engines of change, communication is the lubricant.
So when we look at the role of the BA there are certain communications activities and, more importantly, outcomes that are required for their role to be effective, and if done well, optimised.

The clichéd line about the BA being a translator between IT and The Business is a clue to the importance of communication in the requirements management process.

While the translation task is not the defining attribute of the role it is a significant one, and it is significant enough to be its own Knowledge Area in the BABOK. Similarly Communications Management is a KA in the PMBOK.

I am participating in the practitioner review of the BABOK and before I dive into the content I wanted to frame my personal views on how BA communication activities should be managed.

It’s easier to review a document if you map out your expectations. That way you can identify gaps or differences in point of view at a strategic level, as well as simply identifying errors.
And being a blogger, I am putting my ideas up here for you to read and possibly share your opinions on.

Project Management
Business Analyst

Picture by nathaniel s at Flickr

Carnival of Business Analysts #6: Requirements Communication

Welcome to another edition of the Carnival of Business Analysts. Regular readers know we are tracking through the knowledge areas of the BA BOK (version 1.6.) The Carnival of Business Analysts seeks out blog posts on the topic of business analysis.

Each month I have nominated a theme and then hunted down posts related to that theme. I am assisted by a handful of bloggers who nominate posts they have written or read, and together we construct this digest of thinking on the edition's monthly theme.

In the first 5 editions we have covered Requirements Planning, Requirements Elicitation, Requirements Analysis, The BA and Quality and the nature of the Business Analyst Role. (You can see the whole list here.)

This is edition #6 and it focuses on Requirements Communication.

To start with, read a quick definition or Requirements Communications from the BA Handbook on the knowledge area.

Then, to reinforce that communications is an important and troubled part of requirements management read what Mike has to say about communication at Leading Answers in “We Don’t Want User Input” Angie at B2T also asks When you communicate is anyone listening? And following on from this there is a post at Seilevel titled “I’m not going to read your requirements.”

So you can see there is a challenge in managing people’s communications bandwidth.

Looking more broadly, are there lessons we can learn from other industries? Nada Serajnik has written a post called Can We Learn From A Public Communication Campaign? And Cinda Voegtli tells us What the Girl Scouts Could Teach Us About Project Communication.

Dave Bouman sums it up with the though that regardless of how you manage your software development, at the end of the day “It's all about Communication...”

So how do we manage requirements communication? James Brausch has put forward a model that may be useful in Four Types Of Systems

Lastly Fred W Black reminds us that “Honesty” is a fundamental to good communication.

This edtion is a bit shorter than usual. I have been busy and so haven’t had the time to search as deeply as usual for content. If anyone has something they’d like to add, please do so in the comments.

That concludes this edition. Submit your blog article to the next edition of the Carnival of business analysts using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.

Next edition will be published 10th March and will be themed on Solution Assessment and Validation.

Project Management
Business Analyst

business analysts, projects, communication, requirements, BABOK,

blog carnival

Effective communication

Good communication is iterative. Each new round of communication and feedback helps parties narrow the opportunity for misunderstanding.

Keep communicating and you learn to accommodate the natural filters and barriers that are inherent in new relationships. What are the barriers? Here are some examples to be aware of;

• Language
• Culture
• Jargon
• Knowledge
• Community
• Focus
  

Project Management
Business Analyst

Communication, training, success

Projects have intimate and direct relationships with user groups. Training and communication are key aspects of a successful implementation. This is not a new insight: watch the clip.

I discoverred this clip at Beyond Blinking Lights and Acronyms.

Project Management
Business Analyst