28 November 2007

Do we need Agile Business Analysts?

Don’t be fooled. Agile projects threaten the role of business analysts on IT projects.

An important thing to consider for Agile projects is that users need to be senior enough to be able to look beyond local agendas at broader business benefit.

Furthermore, the BA can be the one to add that broad view, but can't replace the senior user, as unless they have worked in the role they can't really know it. Additionally the business unit hasn't ‘bought in’ to the new system if done by proxy through a BA. The business definitely needs to send in their user/s.

We had a short discussion about this topic at Better Projects a while back and the consensus was that a BA can't replace the business representative on an Agile project – mainly for the above reasons.

In fact, on Agile projects the developers are expected to do the analysis in an agile project. That’s why they require A-grade team members and work best in less complex business environments.

Potentially a Business Analyst can participate in the team to add depth and skill to the analysis. Certainly they could be working on the next (or future) iterations while the development team are busy building this round.

Another alternative is that the skills of the business analyst are adopted by Agile developers. Teaching Agile development teams the disciplines of business analysis will help them accommodate more complex business environments and deliver more consistent results and in the end better projects.


27 November 2007

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

25 November 2007

Hard and Soft Project Management

I wrote last week’s posts as a result of reflection of some work I have done where there were no tangible outcomes, no clear objectives and in fact the only way to tell if I have done anything is by the absence of trouble. And then it’s only a case that my contribution may have helped.

My reflection got me thinking about how you go about managing projects when the outcomes are clear versus when there are clearly defined outcomes.

I came to the conclusion that you need to think outward for intangible projects – to direct your efforts at people external to the project team. And when you are dealing with a clear outcome you are better off focusing on managing your team so you deliver the right level of quality within the time and cost constraints.

Naturally there is a degree of internal and external focus required for all projects as it is rare that things are sitting at the extremes of this spectrum.

My reflection didn’t satisfy my own curiosity so I researched via the Internet and found plenty of info on the issues of hard versus soft management.

Project management in general tends to come down in the hard school of management. We do things for measurable benefit and do them in a scientific manner by breaking work tasks down and allocating them in the right order to the right people.

(Strangely enough project managers are also known for managing without authority. That is; people report to you for the duration of a project within the scope of project work, but they are still spending most of their time reporting back to a line manager who can prioritise the project team member’s time contrary to your best laid out plans. In that context you have to lead with other skills, such as negotiation, charisma, leadership and so on.)

Anyway the point of this post is to share a discovery with you. I found an article called “Hard and soft projects: a framework for analysis” by Lynn Crawford and Julien Pollack which talks about the same issues of tangibility and people versus expertise based project management.

In the article the authors list seven dimensions of a project that can help you determine what sort of project you have on your hands and thus how you should go about managing it. The seven dimensions are;
  • Goal clarity
  • Goal tangibility
  • Qualitative versus quantitative success measures
  • The degree of influence exerted by external stakeholders
  • The range of potential solution options
  • Relationship versus expertise based perceptions of value by stakeholder
  • Facilitative versus expertise based project manager style

Go and check out the article for a more in depth discussion.

Now that you’ve read the expert’s views go back and see what thoughts this inspires in the context of my posts. How should you change the way you are managing your projects?



Ref; Lynn Crawford and Julien Pollack Hard and soft projects: a framework for analysis International Journal of Project Management Volume 22, Issue 8, November 2004, Pages 645-653


23 November 2007

Reminder; A Carnival of Business Analysts on Requirements Analysis

A reminder to submit articles and blog posts on Requirements Analysis. What tips, techniques and tools do you use to analyse requirements effectively?

You can either use the Carnival Submission Form or eail me directly, using the email icon to the right. (Off topic submissions will be ignored.)

I look forward to your contributions.

Deadline is 4th December.


22 November 2007

ill-defined intangibles = external focus



Increasingly projects are starting where the end outcome is not so clear. Instead of a project being started to deliver a CRM system, the project today will be about improving average customer spend. Instead of a project to build a dashboard report the project will include identifying what should be reported on and so on.

When you start a project and the problem is still only partly defined, you typically can't have a clearly defined solution. That's the rationale behind the Agile Manifesto which suggests you build iteratively and work out both the problem and solution in increments. It also applies to decision-point-gated, waterfall type projects.

What it means for the project manager is that instead of focusing in on the work and spending your energy on making sure the job is well done, you spend your time managing external expectations. Rather than working the plan you are mediating the expectations of both the project team and the client and stakeholders. Both sides of the see saw will need to have their expectations moulded so that over time they converge.

When everyone is working to the same vision you have a chance at success. To get there you need to do things to make the software or business process tangible. You can use demos, prototypes, and pilots as tools for this.

Feedback from presenting these incremental developments becomes vital for the project team. Where possible have them in the room with the stakeholders when you demo your new tools. Hearing the feedback directly helps them get a sense of what is important and how the development needs to be adjusted.

Another thing you'll need to consider is that you'll be so busy managing stakeholder expectations and relationships that you won't have so much time to manage the team. In project like this having the right people is even more important. They need to be able to work without your leadership and monitoring them on their work. They also need to be pro-active and knowledgeable about project management processes so that things like requirements, risks and changes can be properly managed. Experience will count here.

As I intimated above, it's a real challenge to get to the end of this sort of project because the end state wasn't clearly understood early on. Basically you are not going to be done building until the client has something they are happy with (and can achieve their business case with.) You, the PM, need to manage them to that happy place and it's not an easy task.


20 November 2007

Requirements defined = internal focus

Projects with clear and defined outcomes are what you think about when you think about a traditional project.

The PMI’s PMBOK describes initiating, then planning a project. During the initiating phase the project objectives are pretty much defined. During the planning phase they become more refined, but basically you are expected to know what you are doing. I am not an expert but I understand PRINCE2 takes a more iterative approach to defining the outcomes, but essentially also expects your project team to have a clear goal.

If you are a project team and someone comes to you with a brief you’ll still need to test it out and make sure you and the client are thinking about the same thing, but basically you are now ready to go.

In these projects you are typically working to a brief, a requirements specification or a design. You take the plan and break down the work then hand it to the experts and off they go. Testing and verification are against the written document and people have a good ability to validate their own work as they go. Testers don't need to speak to the client - they work off a plan or specification doc.

The whole focus of the project manager in this type of project is on optimising the performance of the team. If team members don't get what the project is about it's the PM's job to help them understand. If people are having problems getting their work done to time/cost/quality the PM takes action.

Some attributes of this type of project are described below.


Important things in this mix are work breakdown structures, a rigorous planning phase, a big requirements specification, thought out scheduling, earned value management, managing the gantt chart (or burndown chart) and of course, making sure you have a good team.

When you build whatever it is you are building you know when you are done. You can then hand over the end product, get paid and move on to the next job.

But what if you or your client aren't so sure about what you want?


18 November 2007

Two types of projects

There are two types of projects in this world; the ones where you know what you are doing and the ones where you don't.

In fact that is one of the key issues in the project management industry today and the reason why project managers have aligned themselves with traditional, heavy planning project approaches or have turned to the free-wheeling ways of Agile and Scrum.

Naturally there is not one true way of managing projects. There is not even one best way for software or business process projects. The best method of managing our project will be determined by the environment you are operating in, and more precisely, the degree to which you understand the problem you are facing, and what you have to do to deal with it.

So, when someone tells you how you are going to run that next project, stop, take a breath and think about it. Do you really know what you're doing? And can you?




17 November 2007

Requirements Obstacle Analysis

There is an article in an edition of Requirements Engineering from earlier in the year on Obstacle Analysis. Obstacle analysis helps work out what to do when things go wrong in the course of software processes.

An example; What do I do when a person doesn’t check agreement to the terms and conditions for an online purchase?

  • How do I want the system to react?
  • Do I want to progress with the order or do I want to force the customer to take the appropriate action?
  • What sort of message do I want to send the potential consumer?

The richer the system the more sophisticated the reactions can be.

Six sigma analysts will think of the Failure Mode and Effects Analysis (FMEA) as a method for this activity. FMEA is where you process map out the solution and look for opportunities for failure. FMEA is less effective for situations where you aren’t analysing a process. How, for example do you analyse failure/obstacles for cases?

An approach could be as follows;

  1. Identify goals
  2. Look at interactions
  3. Gauge failure opportunities
  4. Assess failure opportunities
  5. Define system behaviours for each failure mode
As a good requirements manager you’ll document the obstacles and incorporate the responses into requirements specifications.

If you are looking for a diagrammatic way to represent your failure modes, or obstacles you could try using decision trees to track and analyse your options.

Another approach may be hierarchical decompositions associated to each use case. Decompositions are good because they help you keep asking the next level ofwhat if questions.

Readers, I am interested in opinions and ideas on how to best manage this aspect of requirements management. I you have some tips, please share them.

14 November 2007

S.W.A.G.

You have to know the jargon to be in with the in-crowd. Here is an oldie but a goodie;

What's your favorite jargon term?




13 November 2007

Authority to Change

Without explicit authority people often feel bound by the rules, when in fact the rules may just be guidelines, or even just the way things have been done recently.

CIOs, Programme managers and other people in positions of authority need to give their worker bees permission to be flexible, creative and effective in order for project teams to be able to deliver the results their clients want.

Henry Mintzberg is a leading thinker in the ways organisations should be structured. His focus has been at the macro level of business and he has two key themes that are relevant to this topic. The nature of the environment demands a certain degree of flexibility or control, and the culture of the organization tends to one or another degree of formality.

When it comes to managing projects, it doesn't have to be either waterfall or agile, and in fact both methods suit certain circumstances. The methodology is second to the people, and when you have good people you want to set them free to do the work.

If you are able to free up your professionals to make their own decisions about how things should be run, one of the key roles of the project manager is that of enabler. The project manager will there to set a vision and to help get obstacles out of the way. With luck, the team are experts in their field. Without obstacles and artifical contraints they'll be a lot more effective and your project will go over a lot better.

The Fundamentals of Business Analysis

This is an interesting diagram isn't it?

Guy Bueachamp of Business Analyst Solutions has written a short article called The Fundamentals of Business Analysis and posted it at Modern Analyst. In it he proposes a structured framework to ensure requirements are valid, based upon the relationship between the projects objective, planned benefits and scope.

I have copied one of the diagrams from the article to get you interested. Go take a look.

It also has an interesting comparison between the roles of business analysts and architects (from the construction industry.)




12 November 2007

Yourdon's Top 10 Software Engineering Issues

I picked up the below slideshow care of Ed Yourdon's site.
The slideshow accompanies one of Ed's presentations on the key areas to focus on in the foreseeable future. In amongst it all there should be at least one or two ideas that get you thinking about how you can improve your projects.

A shortlist of the top ten issues to manage for better projects.

  1. You can’t control what you can’t measure
  2. Peopleware
  3. Incrementalism
  4. Iteration
  5. Repair costs
  6. Tradeoffs are non-linear
  7. Reuse is important
  8. Risk management provides insights
  9. Consistency trumps brilliance + death-march
  10. Don’t reinvent the wheel

What does it all mean? One of the key themes for me was the recurrance of the human aspects of project mangement - managing people and managing change.

Watch the slideshow, click through to the links. Come back here and share your thoughts with me.

11 November 2007

Want to Shine as a Business Analyst or Systems Analyst?

Modern Analyst is one of the best resources for business analysts and systems analysts on the web today. I want to share some information about it with you.

Early this year I made the online acquaintance of Adrian Marchis, a manager of a team of systems analysts in Los Angeles. Adrian had blogged a few posts on the topic of requirements analysis and business analysis and I had come across them when browsing for topics for this site.

Since then he has started up an excellent website resource for business analysts at Modernanalyst.com. I liked what he is doing so much I have become an active member of his site. Go there and you'll see my name all over the discussion boards.

If you are a business analyst or systems analyst I highly recommend you visit Modern Analyst - and sign up as a member. It has a stack of features for both beginners and experts. Unlike many other profession based community sites it is free to join. (It also has it's own Facebook community)

And it is a community. It's a place for senior analysts to share their knowledge and skills with others. It's a place for people to share new ideas about the roles and the work. Juniors can come, ask questions and learn more about the role and grow in their competency.

By the way - If you are experienced and are wondering what a site like this has for you, the best way to stretch your skills is to teach others - it's amazing how this makes you reflect and improve what you think you are already doing well.

The site's features list includes
  • The ability for members to start their own blogs with a built in niche audience of analysts,
  • An active discussion forum with loads of content from tips on how to get that first BA job, getting through interviews and specific tips on skills and getting things done.
  • One of the discussion threads is currently hosting a requirements management role-play with junior analysts doing the requirements elicitation, and with Adrian acting as the client and coach, giving feedback along the way
  • A library of topical articles collected from around the web including both magazine style and serious peer reviewed academic articles on the topics of requirements management and analysis.

There are more features, but that's enough from me. It's only a click away for you to take your own tour of the site. Go now and join if you like it. Let me know what you think.



3 November 2007

A Carnival of Business Analysts #4; Requirements elicitation





Welcome to the November 4, 2007 edition of The Carnival of Business Analysts.

This month I have focused in on Requirements Elicitation, one of the key processes the IIBA define in the BABOK. If you submitted a BA relevant post, but nt on elicitation - thanks but I had plenty of content to deal with.

Actually, most of these posts were sourced by me and and google. I'm still hoping for more support in compilting this list - especially from regular reader - so next month people; lend a hand! Next month's topic will be Requiements Analysis.

So - On with the carnival...

A little bit about Requirements Elicitation

Bob Robason writes about how requirements are important regardless of whether a project is following an agile or waterfall development model at Bob Robason on Software Excellence in Waterfall vs Agile Development.

Barbara at the Business Analyst Blog says “It’s good to have a developer during requirements elicitation” for the added technical expertise and to help short circuit communication breakdown later on in the development cycle.

Akram has a blog called Business Analysis Skills where he writes quite a long post of Requirements Elicitation. His essay looks at the problem teams face with requirements elicitation and them proposes a model he calls Active Structure for effective elicitation.

Ed” at Hacknot writes an interesting article called The three ages of the developer where he identifies that even though getting the requirements right up front has the biggest potential impact on a project’s success, it actually gets little relative attention. (Hacknot also has an e-book of essays on the topic of software development you can download for free.) The three ages are the age of coding, age of design and age of requirements. Go read the article.

The practical bits

Karel Vandenberghe presents 5 Essential Thoughts for Open Source Innovation posted at Open Innovators, saying, "Pioneering process management today crosses the boundaries of traditional silos. The focus of open innovation is on collaboration and external idea sourcing.

Adrian Marchis presents The Popcorn Way and the Business Analyst posted at Modern Analyst, saying, "How do you know when you're done eliciting requirements?"

Jon Babckock pointed me to the Trials and Tribulations of a Business Analyst blog where the author reminds us that big picture Conceptual Thinking is part of the elicitation process.

Keith Mathis has a series of fiver articles on requirements interviews. You can read the first one here at PM Hut.

Kaka lists some strengths and weaknesses of eight different elicitation techniques at My Learning Path in Requirements gathering techniques.

Trent warns against over-thinking the problem with Beat Analysis Paralysis: Don't Let Good Projects Go Bad at his blog Just for Show. He specifically focuses in on people and leadership. I particularly liked this post.

Robert Rose-Coutré writes about how to identify implied requirements at Sticky Minds in his article Capturing Implied Requirements. My key takeaway from this article was that analysts and requirements managers need to understand business processes to best identify those tricky, unspoken expectations.

Michael Madigan has produced a clear and probably useful “How to” presentation on Requirements Elicitation. It focuses on the human challenges of effective RE at the front and then follows up with some practical techniques.

Scott Sehlhorst has written an article assessing each of the main requirements elicitation techniques in a post called Elicitation Techniques for Processes, Rules, and Requirements at Tyner Blain . If you read this article you will be better able to pick and choose how you go about your elicitation activities based on what particular part of a system or process you are investigating. (In fact maybe I should have included it in the requirements planning carnival.)

Ezie Ann gives some example interview questions (with answers) for you at her livejournal site under the title Requirements Elicitation Round 1.

Lo and Hi fidelity prototypes are compared by Tubious in Prototypes- From the Stakeholders Perspective. It’s a longish but interesting article. And referenced!

R.S. Pressman & Associates present a 22 point Requirements elicitation checklist with the explanation; Eliciting requirements need not be like pulling teeth … but sometimes it is. The problem is lack of preparation by the software engineer and lack of interest by the organization or person requesting the work

MJMurphy highlights he importance of active listening skills in Are you listening? At Seilevel - requirements defined.


Dennis Somer writes a post of effective meeting management PMHut in How to conduct meetings like a top performer. As most requirements elicitations happen in meetings of one sort or another this is quite relevant.

Amaya writes about ‘Beautiful requirements' at Portrait of a Business Analyst in a post called From Necessity to Nefertiti.

Lastly, a presentation on Requirements Engineering in the context of object oriented development. It comes with a section to translating use cases into objects.

Some more useful Requirements Elicitation resources

  • Modern Analyst’s Requirements Discussion Board
  • Requirements Engineering Yahoo Message Group


  • 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.