30 September 2007

Carnival of Business Analysts #3; Requirements Planning


Welcome to the Carnival of Business Analysts #3.

The theme of this month’s carnival is requirements planning.



Last week I published an introduction to the topic of requirements planning. The BABOK identifies requirements planning as a key BA activity. It’s an important topic because bad requirements cost the projects industry plenty of money, the confidence of stakeholders and the reputations of project workers.

If the concept is new to you have a look at what I wrote before delving into these blog posts.

On requirements
Firstly a couple of posts on the topic of defining requirements. After all they can be different things to different people and of course in different methodologies.

Jeffery Paul Anderson of Leader4Success writes about the challenge of managing requirements in complex environments, and gives an example of a model used by Digital Equipment Corp in The requirements factory

Roger Cauvin writes on the difference between requirements and design in Wiegers on the Requirements/Design Distinction

Krishna Kumar presents Agile Development and Requirements Management posted at Thought Clusters.

Jonathan Babcock presents an article on keeping the solution out of the requirements in Avoiding the “How” Trap in Requirements Authoring

Estimating
The beginning of most projects is the planning phase and one of the principle activities is estimating the work activities and the effort and time they will take. Project managers come to you and say how long will it take to define requirements, and how many BAs do we need? Everyone underestimates, even the most experienced people.

I used to recommend analysts break down the tasks, think about how long it all takes, think about the day to day management and activities, the delays in getting into people's schedules and then double your estimate. Then double it again. Other people have other methods;

Scott Sehlhorst presents Scheduling requirements changes - part 1 and Part 2 posted at Tyner Blain, saying, "A two part article on how to manage and plan for changing requirements in an incremental delivery process."

Kupe at B2T Training writes on how each BA’s work plan will be unique and urges BAs to reflect on how they tackle work in Requirements Planning is Personal.

Mike from Leading Answers writes about prioritizing functional and non-functional requirements in an agile context, but of course the principles apply more broadly than just Agile projects in Smart Planning: Balancing Functional and Non-Functional Requirements.

Techniques
This part touches on some of the activities used to gather and manage requirements. It's not n exhaustive list but it my give you some ideas you can use on your next project.

Rajeev Singh at Portrait of a Business Analyst writes about preparing for interviews and workshops in Process Study and Client Interviews

Andre Oporto presents Getting Started With Use Cases posted at Inside Infogenium.

James Taylor extends a CIO article with 1 MORE thing CIOs should know about requirements posted at Enterprise Decision Management - a Weblog, saying, "A discussion of some of the issues addressed by separating rules and requirements" That’s right; there are requirements and there are other things that you will be collecting or otherwise dealing with along the way, including business rules.

And related to this is the business case, Raj Sheelvant presents Perils of IT Budgeting posted at IT Strategy, saying, "Ways to get project funded"

Writing for your audience
Requirements are a message and they are targeted at a couple of different stakeholders; the sponsor and stakeholders want to know what you plan to build and how it will help them solve their business problems, the developers need to know what they have to design and build, and the testers need to know what they are testing for.

Michael presents Speak their language - Tailor your message! posted at Data Governance Blog, saying, "In any project you do, you must always tailor your message to the audience you are targeting."

Louise Manning presents What drives your stakeholders? posted at The Human Imprint advising a deep understanding of stakeholder motives.

Craig Borysowich writes on 'Managing Buy-in' Keys to Success at Tech Architect, saying, "The keys to successfully making people want to accept change are leadership, vision, and communication."

Brad Kuhn at Carnegie Quality writes about The Role of Testing in the Requirements Process.

Stephan Meyn at Process Mentor writes about some things developers are looking for from requirements in You have requirements

That concludes this edition. A big thank you to all the contributors (and to the authors I added myself.)

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 month's theme is Requirements Elicitation.


28 September 2007

Two For One; Harrin on PM Models

If you are thinking about Project Management Certification or are wondering which project management framework is best for you and your project there are two main models to choose from; PMBOK and PRINCE2.

They both have their strengths and weaknesses, and yes, I have written about them before.

This week fellow PM blogger and author Elizabeth Harrin writes on combining PMBOK and PRINCE2 at Projects @ Work in an article called Two for One.

Her views match mine; that PRINCE2 is not a bad model if you want support from a defined process, but you need to understand it well and customise it to your own project's requirements. A warning though; process goes some way to managing quality but process alone can't ensure project success.

For that you need to turn to the people on your team; make sure they have the knowledge, skills and motivation to deliver your project, and that's where PMI's PMBOK comes in. PMI's a knowledge based framework, rather than a process oriented one. It's approach is that you get talented people and train them in the skills. Then you sick them onto projects.

Rounding up Elizabeth's article; An overall knowledge of the PRINCE2 process will complement the knowledge based PMBOK. In the case of project management two frameworks is better than one.

Elizabeth Harrin, Two for One, Projects @ Work, 27/09/2007

26 September 2007

Business Analysis case study

Joe from the Youtube channel Darwin's Hamster has posted a video he made for work on a database project he did for a court management and reporting system.

It's another good case study and is useful for both the new and seasoned business analyst. It gets quite technical as it goes on, but you need to know this stuff.

Set aside your lunch break (27 minutes) and take a look at the clip.

Business Intelligence Demonstration






24 September 2007

PORNO Management; Project Management 2.0

The power of the acronym is amazing. For example you have probably heard of SMART objectives but do you know it's background?

Coined in 1957 by Peter Drucker the term was designed to give some immediacy to objectives, and an ability to track bigger objectives as they are incrementally achieved. This was in the context of the management by objectives (MBO) approach to doing business.

The idea of managing by objectives was neatly summarised by General Patton when he said “Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”

While MBO was superseded as a management paradigm years ago, the SMART acronym lives on.

Project Management is a solid approach to management, but as we know it has its weaknesses and so maybe one day it too will be superseded. When that happens some of its strengths will live on, morphed into whatever takes its place. To help this happen I present you with PORNO management.

PORNO captures the essence of the technical aspects of project management. The acronym stands for;

  • Planning – to ensure you have a solid understanding of the problem and the activities that need to be done.
  • Organising resources - so that the right people and tools are available at the right time
  • Requirements - are the definition of what must be delivered and a focus on requirements is the essence of good project management
  • Neutralise risks and issues – which come from the uncertainty of dealing with a changing environment
  • Outcomes – everything should be geared towards these and these are where you measure your effectiveness

I hope this framework helps you in your search for a simple way to package up project management methods and knowledge on your journey into better ways of managing work.

;-)




21 September 2007

Requirements Planning

The next edition of the Carnival of Business Analysts is themed around Requirements Planning.

It’s a challenging topic because it’s a relatively new for most people including many analysts. I look forward to reading people’s submissions (and of course supplementing them with my own search.)

Submit your blog post, article or white paper today.

Usually a business analyst will join the project at inception or shortly after the project’s scope is defined and then jump straight into requirements elicitation & definition. The IIBA and their BA Body of Knowledge recognises that Requirements Planning is a critical step in a quality requirements management process, and as a result it is listed as one of the main processes for Certified Business Analyst Professionals.

Requirements Planning is important because usually requirements management is a complex activity that takes more than interview or workshop to understand all the business requirements. In large organisations it is also common for several analysts to work on one project, and so co-ordinating the work of several people becomes an issue.

As a method of insuring quality and minimising errors and rework a planned approach is recommended. Essentially you are encouraged to treat the requirements management process as a sub-project of the project you are working on. The BABOK (v1.6) highlights the following areas as key to requirements management;
  • Identifying stakeholders and key roles
  • Selecting requirements activities,
  • Managing the requirements scope,
  • Communication of the requirements.

There are other industry bodies of knowledge that can help in requirements planning. You can look to these for ways to help plan your requirements management project.

The SWEBOK (Software Engineering Body of Knowledge 2004, available for download at http://www.swebok.org/) has useful information for requirements planning. See chapter 2 in general and more specifically Chapter 2.7 for a list of practical considerations for people planning requirements.

These tips include facing up to the iterative nature of requirements definition, managing changes to requirements the importance of fleshing out requirements with background details through a description of their attributes, ensuring traceability, and lastly making sure requirements can be measured (and are presumably the right things to be measured.).

The other obvious source of planning advice is the PMBOK, cousin to the BABOK. The PMBOK has planning embedded into each major work activity and process. It also recognises planning as the second (after initiating) of five project management processes. The PMBOK takes an engineering approach to project management and so everything in this framework is process oriented, as it is in PRINCE2 and most other PM frameworks.

And there are several more frameworks. You can even develop your own. I'll point you to Josh Milne’s blog where he discusses the process of creating a customised project management (and planning) methodology as an example of how you can develop your own process.

20 September 2007

Specifying Good Requirements

Donald Firesmith has written an excellent article on Requirements Specifications. (Thanks to Jonathan Babcock for highlighting this article.)

"Many of the characteristics of properly specified requirements have been well known for many years, at least among professional requirements engineers. Yet most requirements specifications seen today in industry still include many poor-quality requirements.

"Far too many requirements are ambiguous, incomplete, inconsistent, incorrect, infeasible, unusable, and/or not verifiable (e.g., not testable). To combat this sad state of affairs, this column provides a questionnaire that can be used when specifying and technically evaluating requirements."

Firesmith's article is a great starting point for new analysts who want to learn the basics of requirements elicitation and documentation. Given that poor requirements are a (if the not the) most common reason cited for project failure this article should be is fundamental knowledge for all project managers and analysts.

And it's a nice refresher for more experienced project workers also.

Read Specifying Good Requirements.

Reference: Donald Firesmith: “Specifying Good Requirements”, in Journal of Object Technology, vol. 2, no. 4, July-August 2003, pp. 77-87.

18 September 2007

Technology and Work


Perrow's technology classification is a decades old view of how technology and work inter-relate. In this context technology is not just computer related technology; its everything from the basic tools of pen and paper to defined business systems.

I think this model is useful in two ways for IT project teams.

1. The user environment
The first is that it helps analysts understand the type of work the client undertakes, and so it helps when defining requirements for new technology. For example, if you are dealing with lawyers you need to develop a different CRM system to the one you would build for a phone company's call centre.

It's also interesting to think about how this framework applies to models like ISO9000 and CMMI. It's definitely useful when considering your users' interaction with your system. Do you want to build a system that forces them to follow your process, or build a system that enables professionals to tackle a variety of unanticipated problems in a number of ways?

2. The software development process
The second is it helps understand the development methodology that is most appropriate to your project. For instance in a well defined problem place, but in a complex environment an engineering approach might be best, while in a poorly defined problem area, but in a relatively simple environment a craft approach may be better.

This gives an idea of why different people see Agile or Waterfall methods as particularly poor or effective and never seem to agree with each other. It aligns with the experience many of us have where large enterprise projects just can't work with Agile, or where a Waterfall approach just locks you into a bad solution.

You can read more about this model by Googling it, or better, by using Google scholar. Here is an article to start you off on your search.

Ethics at work

CIO has an article on ethics;

"...the moral center of every company lies within its leaders. Those leaders are and should be held to higher standards of ethics and morality—because they are leaders."

Please take a moment to read the article. I am not advocatng their opinion, but do want you to be thinking about ethics and the way you work.

Ethics are critically imporant to your career. They are also critically important to you personaly, as the decisions that you project workers make have major impacts on other peoples' lives.

17 September 2007

Requirements Management case study; beyond formal processes

There is a lot of talk about how to document requirements properly. Let me tell you what I did the last time I delivered a set of requirements. It’s not a classic case of formal requirements management, but it got the job done.

The context
It was for an international corporation and the development was being done by vendors, not an in-house IT team. The organisation was highly bureaucratic and had detailed software development and project management processes. The project has a budget of more than $1 million and it involved a major BPR effort supported by a new website for external agents who do work for the business. The process was being wholly re-engineered and was not n incremental process improvement; there were no new actors in the process.

The method
My smal team of analysts worked closely with the manager responsible for the business process and got to understand his business intimately. After several weeks I drafted a one page hybrid use-case/data flow diagram, dummied up an example web page in excel (yep - excel), and provided a list of dot-point non-functional specs. It was all bundled into one six page PowerPoint document. I flew to the vendor site with a copy of the corporate branding guidelines and work-shopped the requirements with their lead developer. They agreed to provide a prototype from my specs over the next week. During the course of the week the developer lead rang me at the end of each day and we discussed the work done so far.

The outcome
70-80% of the functional requirements made it to the prototype. The non-functional specs could be reliably estimated. We had a tool to begin the stakeholder buy-in exercise. At this point I left the project and another team took over the next stage of the project. My method was validated and the project ended up being a solid success, coming in substantially cheaper and faster than a business as usual approach would have provided.

I provide this example to demonstrate that there are many ways to address requirements management. Essentially requirements management is about communicating needs to developers, and making sure they are the right needs with the client/sponsor and key stakeholders. At the end of the day quality requirements management comes from high intensity communication.

That’s the first and last job of the business analyst.

Peace Day is September 21



14 September 2007

Hello Henry

Hello regular readers,

Henry joined our family on Wednesday Morning, a week ahead of schedule. He's very well and so are his parents.

Natually, things will be a bit slower around here for the next couple of weeks.

11 September 2007

The Business Analyst as Senior User

Here is a concept from Prince 2 care of Max Wideman’s project management site.

“The Senior User is responsible for the specification of the needs of all those who will use the product(s), commitment of any required user resources, for user liaison with the project team and for monitoring that the solution will meet those needs within the constraints of the Business Case in terms of quality, functionality and ease of use.”

Additionally, Agile projects pair programmers up with business users who sit there to articulate requirements and offer feedback to design decision and solution construction as they go.

Naturally businesses that have the good sense to have business analysts on board will use the BA in this role rather than an actual frontline user as BA’s have a better ability to analyse and articulate ideas.

So, Business Analysts can be viewed as senior users, right?


What do the project managers that visit this site have to say about that idea? Especially when it comes to user acceptance testing?



9 September 2007

Balanced Scorecards for Projects

"Managing Strategy is Managing Change" is a slideshow on applying the Balanced Scorecard principles to project management.

Balanced scorecard is a mode of defining success according to a balanced portfolio of metrics, usually including financial performance, customer satisfaction, process compliance, and growth potential.

Take a look at the slideshow. Maybe you can use some of the ideas in your next business case.


From: ddebowczyk, 5 months ago

Balanced Scorecard IT Strategy and Project Management - by Glen B. Alleman (Kaiser-Hill Company)


7 September 2007

12 breeds of clients

A lighthearted article on dealing with difficult clients: 12 breeds of clients and how to work with them

5 September 2007

The Scope of the BA role; a diagram

This diagram represents my thoughts on the BA role. It shows what high level activities a business analyst does and maps hem against a typical SLDC (or iteration for the Agilists.) The size of the shapes also represents my view of a rough weighting of the work at that phase.

The diagram is provided for discussion and so I would very much appreciate comments from those of you who have a view on how the BA role should be managed.

4 September 2007

Carnival of Business Analysts #2; The Business Analyst and Quality


Welcome to the September 4, 2007 edition of the Carnival of Business Analysts. Thanks to the many contributors. Thanks also to the people who's posts I have added myself. Without furher do, read on and be educated.




CA presents Hey, where are the bugs anyway? posted at Atlantic Canada's Small Business Blog, saying, "How would you get from “It’s a buggy product” to “Hey, where are the bugs anyway?”"

edithyeung presents Steps You Must Take to Run a Successful Meeting and Say Goodbye to Boring Meetings posted at Edith Yeung.Com: Dream. Think. Act., saying "Successful meetings don’t happen by accident. It takes serious planning and thinking. With my 10 years experience running thousands of meetings, I have developed a few tips for meeting organizers."

Luke Houghton presents 5 ways to think strategically posted at Luke Houghton, saying, "This article discusses the importance of thinking strategically and illustrates 5 ways this can be done."

jonbab1 presents McDonald's Burgers and High-Quality Business Analysts posted at Jonathan Babock, saying, "The instructor of a training session I recently attended used an analogy that I liked. He asked whether we thought of McDonald’s as a high-quality restaurant. The question drew a few chuckles and, of course, most of us replied that we did not. He then went on to explain that, in fact, McDonald’s is a high-quality restaurant, and here’s why...."

Ben Yoskovitz presents The 4 Immutable Laws of Giving Great Proposals posted at Instigator Blog, saying, "Most projects start with proposals. Here are 4 laws to help you write better ones."

Renata Vincoletto presents > systemcall dot org » Product Development cycle posted at > systemcall dot org, saying, "At the beginning I thought that only small companies had dead locks on the development cycle but after going through several companies, big and smalls, commercial and academical, I see that the problem is everywhere."

Louise Manning presents He who fails to plan, plans to fail. posted at The Human Imprint, saying "How good are you at planning? Are you a thorough planner or the kind of person who thinks on their feet, maybe you are someone that falls somewhere in between?"

evelester presents Tips on making a Home Office Schedule posted at Home Biz Blogger, saying "These are general time management and effectiveness tips suitable for anyone who has to mnage their own time."

As usual CraigBrown has to have get inolved and offers several posts;

Lastly Kingsley Tagbo has offerred an article related to the first carival's theme of defining the role and getting into the BA career. He presents How To Become A Business Analyst posted at HOW TO LEARN COMPUTER PROGRAMMING FAST OR GET A JOB EASILY.

And so that concludes this edition. Comments on what articles were good and what were not so good would be great so I can work on ensuring good quality.

As for Next Edition: I am thinking I will follow the BABOK themes as carnival topics over the next few months. So, next month's theme; Requirements Planning.

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.

2 September 2007

Project Management in the Legal Industry

I am writing a thesis on project management and the law. The basic ideas are that the legal industry needs a unifying framework for managing the varied and unique types of client matters they handle and that project management fits the bill.

In the course of my research I have discovered ITLA, the International Legal Technology Association. ITLA are not dealing with the space I am researching. They are the organisation that is helping to mature the subset of the IT industry that services legal firms.

The legal profession is an interesting case study for both IT and project management because it comes with so much history and tradition, and at the same time it's facing an industry wide challenge to modernise and provide faster, cheaper solutions to clients in a more complex environment. That's fine, because banks, gas companies and bookstores have gone through similar challenges.

The Legal industry is different. Law forms are an association of professionals and they seriously resists the typical process engineering and task standardisation that comes with an IT overhaul. And something still has to change.

As with banking, gas companies and bookstores, IT leads the charge to bring project management to the masses. ITLA for example posts a series of white papers, many of which talk about the challenges of IT project management in the context of law firms.

Last month an article was published called "Project Management - Broadening Your Scope."

A summary;

Over the past years, the application of project management fundamentals has firmly set its foot in the door of our member organizations, and with that, project managers are now a part of the IT or administrative staff.

Whether you're just starting in the PM arena, fine-tuning your PM skills, collaborating with vendors or considering a project management office (among other things), you will find answers to your questions and perhaps some new ideas inside.

We gratefully acknowledge our authors for sharing their expertise, knowledge and fresh ideas you can apply to open the door wider.

There are more papers and if you are an IT worker or PM in a law practice you should take a look at the ITLA website.

My research is looking at that next phase; where project management moves into operations management and becomes the default way of dealing with a client's work.