Search This Blog

30 April 2008

Efficiency and effectiveness and getting on with business

Efficiency and effectiveness are often cited as reasons for running a project. "We need to be more efficient and effective"

But are they the same thing? No. And in many instances they are opposite forces.

Take for example taxation. A review of Australian tax laws is on the table at the moment and one of the things the experts are going to have to address is the balance between ease of execution (efficiency) and achieving the right policy outcomes, which are about equity and economic growth (effectiveness.)

In a corporate environment you can find many examples of efficiency and effectiveness being counterpoints. The more you sell the more expensive customer management becomes. Often the larger you get the lower your margins. The faster your call centre staff churn through calls the less satisfied your customers become...

Project professionals are in a fantastic place to influence the choices organisations make about how they grow into the future. But you need to understand the implications of these choices.

When you put efficiency and effectiveness into your project goals for the product or service you are building you need to consider which one of these is most important and why. Does enabling call centre staff to handle 100 calls per day make them better than answering less calls but doing a better job of dealing with the customer enquiry?

Deep knowledge about information systems and technology solutions doesn't help you with questions like this.

I think our focus on technology and process has led us to miss some key strategic questions, which mean that today our experience as consumers is often one of frustration and disappointment.

A deeper understanding is needed by project people about how and why business works. Even if you are at the tactical end of the spectrum it will help you develop your views on requirements management and project strategy so that your projects deliver better long term outcomes.

Here is a couple of resources to consider in your journey to a better knowledge about the business side of project management and analysis.
These are Wikipedia entries. You'll have to dig further to get the full view, but each is essential for your professional toolkit.

Lastly, don't forget further study; Online classes can make you and your business more efficient. 

Picture thanks to Dru! @ flickr
This post is sponsored

28 April 2008

BABOK Review: Now it's your turn

Version 2 of the BABOK is open to all to review.

There are a bunch of us who have done an intensive review of one or two chapters, but anyone can download the draft of the BABOK version 2 and provide feedback via the IIBA's online survey.

Access them here;

Personally I feel that the BABOK is an important document. It will shape the way BAs and their team mates in the project industry perceive their role. It will limit some practitioners and enable others, so it's a mixed blessing. Just like any defined practice.

And as an important document that will affect your career, it is important for you to go and review the document and give your feedback. You have until May 15th, when the survey will be closed. That's about 2 weeks.

If you feel like going the extra mile, come back here and drop your comments, either on this post or via an email.

Thanks for your time.

Thanks to Creative Commons,

25 April 2008

Requirements Management - the Six C's explained

I am putting up straw man ideas about requirements management and communication prior to me reviewing the draft chapter in version 2 ofthe BABOK. This is so that I can get my ideas straight before I go and review what the commitee have put together.

So far I have run through my ideas on Requirements Communication an am now looking at Requirements Management processes. Last post I put forward a model for requirements management called the Six C's.

This post I want to explain the six Cs of Requirements Management in a bit more detail. When you have read my thoughts I am very interested in your comments.

Each of these ideas (Cs) is described below, followed by putting them into the context of both Waterfall and Agile development processes.
  • Concept - High level ideas about what the product will do.
  • Clarity - Requirements elicitation, and analysis. Defining the requirements through workshops, interviews and so on, and then documenting them or implementing them into a system that can track changes and act as a control point.
  • Consensus - Socialisation and approvals. Get stakeholders, the sponsor and project team to agree that, yes, these are the requirements.
  • Commitment - Addressing requirements in the solution design and allocating resources to build the solution.
  • Control - Control process applied to requirements; understanding the impact of changes (and possibly making sure the developers stay focused on the requirements while building the solution.)
  • Confirmation - Validating requirements in testing and implementation. Audit solution design; check that the requirements have been addressed in the solution design, and if not, what are the impact to the business case and what is being done about them.
So, let’s apply these concepts to the Waterfall and Agile processes. I figure that Waterfall and Agile are opposite ends of a methodology spectrum and so applying the 6c concept to both processes will illustrate the universality of the concept.

24 April 2008

Requirements Management - the Six C's

Next point; Requirements are managed through a process. Two that we often mention here are Waterfall and Agile. There are others also, including Six Sigma (DMAIC), Rational Unified, generic process improvement and so on. Let’s have a quick look at RM processes in the context of Waterfall and Agile.

Waterfall processes are formal, gated, and sequential.

Agile and iterative processes are informal, delivered in phases or releases and cyclical in that each release goes through mini SDLC processes.

There are consistent lifecycle stages that requirements pass through. Because I like a catchy phrase I have coined the 6 Cs of requirements;
  1. Concept
  2. Clarity
  3. Consensus
  4. Commitment
  5. Control
  6. Confirmation

Nice work huh? Next time, explaining the 6Cs.

23 April 2008

Requirements Management - formal and informal contexts

Good requirements management means your project will run more smoothly and you’ll have a better chance at achieving the business outcomes described in your business case. (If you want further evidence of this read this post.)
So, plan your requirements management activities in advance and you’ll have a smoother journey.

One of the first points to note is that Requirements Management (RM) can be formal or informal, but if you are developing a product or system it is always there. You won’t be the one to pick a formal or informal process, but you are going to have to accommodate both over your career.

It’s likely that no-one will come up to you and say “Hi, I’m Craig, and around here we run pretty informal projects.” So you’ll have to look around to work it out. Here are some things to help you identify the degree of formality you’ll be working in. Consider these things;
  • What is the client organisation’s culture
  • What is the performing organisation’s (project team’s) culture
  • How complex are the stakeholder relations on the project (a good indicator here is number of close/allied stakeholders and external/unallied stakeholders.)
  • How dynamic or stable are the requirements going to be? (eg does the sponsor know what they want?)

Next: RM processes.

Picture by Splorp at Flickr

22 April 2008

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

21 April 2008

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.

20 April 2008

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.

Picture by Splorp at Flickr

19 April 2008

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.

18 April 2008

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?

Picture by Splorp at Flickr

17 April 2008

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.

16 April 2008

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.

Picture by Splorp at Flickr

15 April 2008

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.


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.

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.

Picture by nathaniel s at Flickr

14 April 2008

Deployment Gone Wrong

Here’s a situation:

Your development team has begun implementing a shared enterprise infrastructure. Nobody on the team has ever done this before and they do not take the time to think about how updates will be handled for the software as more applications begin to use it.

The first version of the shared infrastructure goes into production but it is not yet complete. There are enhancements and bug fixes that need to be done before it is fully implemented. Meanwhile, there are multiple applications being written to use the shared infrastructure. All of these projects are running concurrently with the enhancements and bug fixes for the infrastructure.

There are many things that need to happen in order for this scenario to work with minimal problems and no outages for the applications using the shared infrastructure. Off the top of my head I suggest that you need configuration management, a well-defined deployment process that is controlled and repeatable, regression testing before anything is ever put into user-acceptance testing or production, and a well-defined and controlled build process to start.

What happens if your environment doesn’t have all let alone any of these controls in place? The answer is that the infrastructure will fail in a spectacular way at the least opportune moment. Let’s look at what could happen if just one of these controls, such as a well-defined deployment process, is not in place.

If you do not have repeatable or automated deployment processes, you could end up missing steps and having the deployment fail anywhere from subtle to spectacular ways. If your processes are not automated and also not well documented, you could end up with just one person who knows how to deploy the product. This will put you in an at-risk position if that person is out sick or decides to leave. This could also lead to critical deadlines being missed.

All of this will make the entire department look bad to the customer which can potentially lead to cut funding or lost contracts. The problem for me, as a business analyst, is that I am not managing these risks on any one project; I am managing them from a departmental process standpoint.

Therefore, I must document the potential problems from this lack of process in my risk plan for every project. Consequently, I will do things such as make sure I schedule the user acceptance testing at least several days after the deployment to the testing environment. Another mitigation plan I might use is to make sure that I have an escalation plan for deployment problems and that I implement it immediately to avoid last minute issues. Risk management and mitigation can avoid some problems, but it will never offer a substitute for good processes.

Clearly this is not a preferred solution. Rather, a good solution would be to have a well-defined and controlled deployment process to limit the risk involved. The process must be developed from within to get as much buy-in as possible. That said, it must also be enforced from above to ensure compliance by all.

In some cases, all efforts to get the department to institute good build practices will fail. Unfortunately, this means the business analyst or project manager must be prepared to deal with the risk as best they can.

Photo by Nictalopen at Flickr

13 April 2008

Best Practice

How often have you sat in a meeting and heard the term Best Practice used to support an argument, or read an article using the term Best Practice as a justification for a particular assertion? It is increasingly becoming an industry buzz word and in doing so is losing its original meaning as it gets used out of context.

Best Practice describes processes and techniques that measurably deliver the best outcome against any other known process or technique for a given criteria. In most disciplines, this is evidence based and when the term is used, it is invariably also done in conjunction with a citation to a peer reviewed study that supports that claim of being Best Practice.

In many industries, Best Practice is somewhat compromised due to the cost of doing studies over statistically significant population sizes. So you have the associated industries funding these studies which can lead to dubious results being published. A classic example of this that most people will be aware of is the tobacco industries involvement in studies into the health impact of smoking. From the opposing conclusions currently being published almost monthly into the health impacts of mobile/cell phones, some people are beginning to accuse the telecommunications industry of attempting to influence published results in a similar manner as the tobacco industry has been shown to have done.

There are some things in IT that we can verify. As an example, using method x vs. method y to retrieve data from the database will result in a difference z in performance. While sometimes difficult and not without its flaws and prone to influence by vested vendor interests such as Sun vs. IBM vs. Microsoft, benchmarking is a measurable approach to ascertaining and confirming Best Practice.

Similarly, longitudinal studies of many projects for the causes of defect injection can identify practices that either contribute to or alleviate the injection of these defects through extrapolation and inference techniques. These studies then contribute to what we understand as Best Practice. Unfortunately, there are many such claims to Best Practice derived from anecdotal evidence, rather than derived from actual case studies.

Some aspects that are termed Best Practice are in reality, simply industry practice. If I'm writing COBOL, everything is upper case. This convention is by industry practice. Whereas if I'm writing in Java, I have different syntactical conventions, and different again with C#. Unfortunately, the term Best Practice is widely abused in the IT realm, and often what is simply a convention for a given community, is erroneously referred to as Best Practice.

In choosing what process to follow under what circumstances that meets Best Practice is fraught with difficulties. The IT industry is unfortunately in a unique position, where the term Best Practice in the traditional sense, usually does not apply for many aspects of a project. Doing a significant project usually runs into the millions of dollars and is a unique undertaking. To ascertain whether one process is better than another in the traditional sense would require the same project to be repeated a number of times using the same process and different people to accommodate for the variance that people introduce, and then repeated for each process being compared, with all other factors kept as similar as possible and for the deliverables to be similar. Financially, it is simply not feasible to cater for such a combinatorial explosion in approach. Often an IT project ends up not being financially justifiable as it is, much less being able to support the same project being done multiple times to ascertain what is Best Practice. So academics attempt to extrapolate from observations, which has limitations in what conclusions can be derived.

Many of the published figures that do exist supporting different processes being Best Practice are based on results obtained from final year students being tasked with following a certain process and compared against the results of fellow students following a different process. These results rarely allow for differences in outcomes that would arise from how the students have been taught up to the time of the comparison, and usually do not have sufficient population sizes for the results to be significant. Similarly, they invariably do not cater for the level of experience in the subjects. You would expect a junior developer to derive greater benefit from a much shorter feedback loop than a senior developer. By how much at this stage is probably academic. But if you base your conclusions that short cycle iterative development is Best Practice based on the result of studies on students, then you already have a bias built in to support that conclusion. This is not to say that short cycle iterative development is not a good practice. But you need to be wary in the interpretation of supporting studies and understand the inherent bias in such studies.

So we have the situation where everything from CMMI, Six Sigma, eXtreme Programming, etc all claiming to be Best Practice and all having figures that support them.

A similar situation exists in choosing how best to notate requirements. Which is Best Practice: UML, use cases, stories, scenarios? Or are they all equivalent? How often have you read articles saying the use of UML and use cases in a CMMI process is Best Practice or the use of story cards and XP is Best Practice, with neither citing a reference to support their claim of Best Practice or citing studies that have built in bias?

When you next read of someone claiming process x is Best Practice with no supporting citation, view it as an opinion, rather than an industry Best Practice. Often that opinion is reflective of the current industry trends, but being the flavour of the month still does not making something Best Practice. If there is a citation to a supporting study, understand the bias in the study that may influence the results and lend itself to the conclusions being made and if possible determine who is funding the study to ascertain what spin may be on the results.

Essentially I'm asking that you do not take at face value any claims of what is Best Practice, whether supported by studies or not. And in your own articles and arguments, be conscious of what Best Practice implies and use it appropriately. If we as an industry become more rigorous in our use of the term, then it may actually start meaning something again. But until then, it will increasingly become a meaningless industry buzz word, if it is not already.

10 April 2008

Requirements and Constraints

A constraint is a statement of restriction that modifies a requirement or set of requirements by limiting the range of acceptable solutions.

While this may initially be perceived as a drawback to the development of a project, constraints in many ways have a powerful way of helping projects work smoothly or reduce the risks of catastrophic failure.

Constraints appear across all levels of the requirements hierarchy (business, functional, system, user).

Consider a system that is meant to be used internally by a company that gets built with functionality for users to access from external sources.

A constraint - "System shall be used by employees of Company X" - elicited, documented and communicated could potentially save not just development time but also reduce risks. Developers, having been informed of such a constraint, will develop features that keep the scope of development to just the employees of Company X.

It is with such an example, that PMs and BAs must do well to capture early, so as to prevent catastrophe and move forward successfully in projects.

Constraints are usually driven by at least three factors: business environment and rules, cost/time/quality balance, and environment such as OS platform, computer languages, product choice, deployment, etc.

Constraints need to account for these factors, but BAs need to be careful of being too prescriptive of the solution, thus limiting options too early for the technical team.

You should never assume what choices the technical team will make. Getting the balance right between enough information to estimate from while not being too prescriptive is one of the more difficult challenges of setting down requirements.

The rationale for a constraint is also important. While constraints are important to have in any project, one must keep in mind that too many constraints captured without proper rationale can ultimately stifle a project. This can limit meaningful solutions that can arise because of such restrictions on requirements.

Karl Wiegers points out that PMs and BAs must ask why each constraint exists, question its validity, and record the rationale for including such a constraint in a requirement.

Test plans must also provide cases for ensuring systems comply with the constraints placed on their requirements. It is also recommended that User Interface options not be constrained at an early stage in the requirements analysis process. Functional Requirements however should be captured as early as possible to risk any re-development of a feature to accommodate the constraint

Photo by Shoothead at Flickr

8 April 2008

The Dirty Harry Approach to Requirements

I just dropped by the wiki; "The Business Analysts Handbook" and saw a new article posted with this as the title.

Click through and read it.

It's a rant by a BA who has been frustrated by their requirements management experiences recently. If you have been in this game for a while you may recognise the story.

While you are there, if you have experiences or knowledge you would like to share, take a moment and put in an article.

As it grows this wiki could become another useful resource for business analysts.

7 April 2008

Project Planning tips

At this time of year there are more than one or two project managers sitting there in front of their project planning/scheduling tool, wondering what's the best way to frame up their plan.

If you are looking for guidance on how to best break down tasks and what deliverable and activities to plan for, take a look at Josh's commentary at ThE pM sTuDeNt.

He provides some really clear and simple ideas that will make your project planning easier.

Here is the post!

4 April 2008

On the Requirements Heirarchy

Twice in the last month I have posted on “The 3 levels of requirements” (here and here).

The topic has also come up in a discussion thread at Modern Analyst which explores what the difference between functional specifications and business requirements specications is. (here)

The three levels are typically called;

Business requirements
Functional requirements
System requirements

Complementing functional requirements there are non-functional requirements. As a result, in some circles the functional requirements are called user requirements. To me this is a neat label because it keeps the focus on users and is a good term for addressing non-technical solutions.

So we can look at the hierarchy as;

Business requirements
User requirements
  • Functional requirements
  • Non functional requirements
  • And the non technical requirements
    System requirements

    To try to explain the relationship of these hierarchies I have put together a Venn diagram. I am interested in your comments, either here on in the Modern Analyst forum thread.

    And after posting the diagram above I realise I have not labelled the "User requirements" - but I don't have time to redo the picture; so be aware it's the second level.

  • 3 April 2008

    Okay, I was wrong

    Apparently you can model everything with process diagrams...

    2 April 2008


    This email arrived in my inbox today.

    Dear Craig,

    Our editors recently reviewed your blog and have given it an 8.0 score out of (10) in the Business category of This is quite an achievement!

    We evaluated your blog based on the following criteria: Frequency of Updates, Relevance of Content, Site Design, and Writing Style.

    After carefully reviewing each of these criteria, your site was given its 8.0 score.

    Visit your website’s summary page on

    Please accept my congratulations on a blog well-done!!

    Amy Liu

    Thanks to Janet, Chris, Raphael and Andrew who have joined the team and posted recently. We did alright although at least one reader and blogger has beaten us on the Blogged leaderboard.

    1 April 2008

    OPM3, Project, Programme and Portfolio Management

    This presentation is on Project Management and how to get the most out of it, including a look at programme and project portfolio management. I particularly liked the visuals on the differences between leadership styles and roles across the three disciplines.

    Thanks to Elmar Roberg for making this presentation available to the world via Slideshare.

    If you have questions or comments leave them below. We'll respond as best we can.

    (View this in full screen mode to see and read everything clearly.)