Search This Blog

31 May 2011

Questions for Initiating Projects

A friend is developing a project portfolio planning process.  I was asking some questions about the decision criteria used to filter and prioritize projects and wasn't satisfied there was enough in the model. I wonder if any of you PPM and PMO readers could offer comment on this set of questions I just made up myself.

Worth Considering?
  • What local and specific criteria apply here for your organization?
  • A sponsor of sufficient authority?
  • Do we have the ability to form the problem or opportunity into a coherent statement
  • Common sense check/are we in this business?
Worthiness check, round 2
  • How important is it in the big picture?
  • What other initiatives are more important?
  • Do we have the fundamental skills and resources required for this initiative?
    • Can we buy/hire/get the right resources?
  • How does this initiative contribute to our mission?
What are the risks related to starting this?
  • Do we have sufficient skills and resources?
    • Do we have sufficient project delivery skills?
    • Specifically who will be responsible for delivery?
    • Do they have the time and ability to focus?
  • Who will take over the product or service after the project?
    • Are they capable of dealing with the outcomes without support?
    • Can we provide sufficient support for the post-project transition?
  • Are we introducing something new or changing something we already have?
Where does this sit in our priorities?
  • Urgency/Importance?
  • Our Motivations?
  • Dependencies?
What does success look like?
  • What is the specific and measurable differences we expect to see in our organisation today?
  • How will you know when you are done?
  • What does failure look like?
  • What are the triggers to stop the project?
Learn from the past
  • Have we tried anything like this in the past?
    • Did we fail? Did we succeed?
    • What were the critical issues that caused failure/enabled success?
  • How will we incorporate this learning into our planning?
If things start going wrong…
  • What tools and systems will we use to discover problems?
  • Who will monitor the situation for problems?
  • What tools will we put in place to enable support?
  • Who will be available to offer support?
There you have it.  My brain dump.  Can you help us out by commenting, and adding or removing thinking points and filters?

30 May 2011

Scope=Requirements Slide deck

Here is the slide deck that supported the previous series of posts.

Concluding this series

So, I think this is both very useful and relatively simple to implement.

As the requirements person, you are in the driver’s seat when it comes to project scope.

There are a whole bunch of activities that make managing requirements a non-trivial activity.

You need tools to help you identify where the problems are and to support the conversations you need to have when negotiation scope/constraint issues.

Lastly, you need to understand your local conditions. Do you align to industry averages? Are you more dynamic? More stable? What data do you have to support your assumptions?

Go get the data, starting next week.

Possibly it’s there in past project reports.

But build up your own repository of knowledge and take it with you. There is a lot of variation in our industry and one person practicing some excellent techniques can make a big difference.

And as the six sigma people out there know, having the numbers helps you win your arguments.

29 May 2011

Implementing this approach /Scope=Requirements/

Implementing this approach requires only a minimal set of data, and you can start the process at any time in the project.

In my example I have tracked the requirements weighted with their development effort. But here is another example of the same data with the estimates removed and instead only the number of requirements tracked.

The difference is the Y axis scale has changed, but otherwise everything is the same.

The reason for this is that the average size of requirements tends to be the same. In some projects you may find this to be different. Many people practicing lean software development track story sizes with a three categories such as small, medium and large. They can then watch how weightings of small or large sized requirements can change patterns in predictable delivery.

Again, I recommend you start simple, and use the data that is easy to hand.

Simply tracking the number of live requirements on a regular cycle will give you some insight into the likely size of the target when the project meets its deadline.
  • Number of live requirements
  • By month
  • And status (Done/ not done)
You can also get a lot out of cumulative flow diagrams which include the “in progress” status. If you do this you’ll probably see problems around too much work in progress. Here is an example of a cumulative flow diagram from the project I have been showing you.

You may or may not be able to track work done by developers as they complete components and features, rather than only at project stage gates. If you can get this information, you will see when the work is actually likely to be completed. Or what features will be completed by the deadline.

And once you have this information you can talk to your stakeholders and project team members about the options available to you.

Do you start working on managing people’s expectations down, do you cut quality? Do you cut features? Do you ask for an extension?

The right approach depends on the circumstances of the project of course. But with good information you can have better conversations.

28 May 2011

A case study in tracking requirements scope

This chart shows a bunch of really interesting things. For example, we base-lined the requirements around the end of April in the first year, but up until that point there had been erratic scope growth.

This was natural enough, as you go through the discovery process. You see that big early spike? That was the wish list of the stakeholders. The following trough is the push back as management – the people paying for the system – sought to shrink the project cost and risk.

You’ll also see that once base-lined the requirements scope still went through some weeks of erratic growth and shrinkage. This reflects the continuance of that negotiation process between the people who had to use the system and the ones paying for it.

Eventually a combination of sufficient negotiation and sufficient product being visible meant the scope changes flattened out.

We even reached a stage where we were successfully negotiation the scope down as we discovered some redundant requirements, and were able to show how some requirements were not as critical as originally thought.

At the end of the day we came through at just over 2% scope growth per month, and had I continued to work with the product and team I would have seen the average scope change rate become even lower.
2% is industry average remember? But it was way lower than common in this context.

By the way, we missed the target deadline on this project, but were able to tell management many months ahead of time. There were no last minute surprises.
And as an organisation we had not just beaten the odds to deliver a successful product, but had learned many things that can help future projects.

27 May 2011

Anticipate change, and plan for it too

Okay, scope changes. We got that.  And now we have some baselines that help us anticipate change.  But forget the scope increase back to our original chart.  What else is wrong here?

Teams don’t have a uniform productivity rate.

For one thing, our estimates on work will have been wrong and some easy things will have turned out to be harder than expected, and less frequently, some hard things will have turned out easier.

Another thing is that teams don’t deliver at a constant rate. People get sick, people get tired, people leave the team and get replaced, people have other things that take their focus away from their job.

All sorts of things happen to us to make us less that uniformly consistent like a machine. The most important one is that we are born human.

So let me show you a real example of one of these charts.
Blue is total requirements size.  Red is work remaining and green is work completed.  Tracking this data is very do-able using the tools you have today.

More tomorrow.

26 May 2011

What does 2 percent scope growth per month look like?

If there are industry numbers that say scope typically increases 2% per month... Well, two percent doesn't sound much does it?  As Albert Einstein said; the Most powerful force in the universe is compound interest.

And who's to say you are industry average.  In the projects I have measured in this way rates of change have been as high as 8%, and at times even higher.

The chart above shows scope increases on our example 200 requirements.  At the end of a year, depending on the rate of increase requirements have per the following;

  • 2% average change = 23% total increase for a new total of 246
  • 4% average change = 54% total increase for a new total of 308
  • 6% average change = 90% total increase for a new total of 380
  • 8% average change =  133% total increase for a new total of 466
What a difference a few percentage points can make!

Two percent is just industry standards. I really recommend you check out what is happening on the projects you work on. Are there patterns? Is there useful information in here that you can use?

The very first thing you can do with this data once you have it is start planning your contingency buffers.  If you are going to run a 12 month project you now know what the likely size of the target really is.
You can also use this information to negotiate for leaner backlogs, or smaller releases.

Right from the start you could use this information to negotiate for leaner backlogs, or smaller releases.

The clock starts on this scope creep stuff pretty much from when the requirements discovery work starts and doesn’t stop until you are in production, so if you have a 6+ discovery period you can see the sort of troubles you are likely to face.

25 May 2011

What grows Two Percent Per Month?

In the previous post I introduced using control charts to monitor requirements scope.  Today I want elaborate that further.

Consider the chart above.  There are a nominal 200 requirements, and over time the team are going to deliver on them.

You can see the size of the requirements completed and work remaining from month to month, over a 12 month period. It’s a nice simple diagram that shows a nice even burn down rate. The project team will probably deliver all product scope on time.

Naturally this diagram is based on made up numbers.

The first thing to note is that requirements don’t stay stable. If you have 200 at the beginning of the project once thing you know for certain is that you won’t have 200 by the end.

I have been readings some books by Capers Jones from SPC in the US. One of the facts I gleaned from one of his books is that the IT industry that he works with have a typical 2% per month scope increase.

When I first heard this a few years ago I was fascinated. I wondered what the scope change rate was where I was working and began to start tracking it on the projects I worked on. What I discovered was that in my context the scope change rate was typically much greater than 2%.

Let’s take a look at some scenarios.

24 May 2011

Google Docs as a Requirements Management Tool? No, Really!

At my day job, we've recently started a new program which will likely be the largest single technology endeavor ever undertaken by our organization. Its got big goals and, assuming we pull it off, will position us more than a decade in front of our leading competitors when it comes to technology integration within the organization. The advantages of our approach is making everyone from operations, finance, support and IT rub their hands in glee. Its got a little for everyone and a lot for some. Its one of those endeavors where everyone is on board with it and the only real complaint is that we're not done already.
Given the high priority and the huge operational need for this project, you might be asking yourself, why on earth would I, a guy who blogs about projects in general and requirements in specific, be dumb enough to pick a hack tool like Google Docs as our requirements repository. Great question, glad you asked. Its actually a long story, but for the sake of not overly boring you, I'll sum up a bit.
One of my favorite features of Google Docs is the drawing function. See, I like Visio for diagrams and even for rough wireframes, but the fact that nearly no one has Visio installed and the license fee is high enough that no one outside of BA's and IT manager can justify the expense in most organizations means that you're forced to output to PDF or past into Word just about everything you create. Frankly, that sucks.
But as nice as the drawing functions are, what really caught my eye was templates. A very short time after the template sharing was launched, I spotted this link for a basic set of wireframes that met my two requirements for any tool: simplicity and usability. I kept the link around for nearly a year before I found a project where it would be perfect.

What I wasn't expecting was how well people have taken to the idea of using Google Docs during our requirements elicitation process. We're totally changing the user interface and business processes used by this enterprise application of ours. Our user community is (rightly so) not thrilled with its current implementation, but, like most user communities, has trouble articulating exactly what it is that would make for a good application that meets their needs. This is where Docs, in general, and the linked to wireframe template, in specific, has come in so very handy.

The Process

Knowing my user community as well as I do, I knew that if we walked in to the first elicitation session with nothing to show, we would spend most of the day off in the wilderness trying to chart a path. So, having spent many years learning the business, I put together a few different sets of wireframes that gave different (sometimes wildly different) takes on what you could do in a modern application.

It was during this process of putting together those initial wireframes that something I wasn't expecting happened; I remembered a great little feature in Docs called 'Sharing'. As a lark, I decided to share off my wireframes to my Director and VP (plus a few other BAs on the team). They were curious as to what I was doing, so I figured the easiest way to make sure they always knew what I was doing was to allow them to proverbially watch over my shoulder.

From that point, things just started snowballing. I added a use case template and the BA creating the use case library for me started adding her docs and sharing them off. She and I use a Google Spreadsheet to keep track of the use cases we've identified, the status of each and as a way to signal to the other what work needs to be done. The best part, although its one we're just now really starting to use, is collaborative editing. We sit no more than 20 yards away from one another, yet being able to watch the other person update a document in real time does wonders for the creative process. I can't recommend this enough.

The best part of this is how successful we've been so far. Everyone has all the information the need whenever they need it. No document checkouts needed. We modify documents, compare revisions and leave each other electronic notes in the margins. No need to print out, mark up and return for review. We make changes on the fly, right in the document.

Our users don't (yet) have a clue how we're doing all this. Honestly, there hasn't been a need as most of my external stakeholders don't spend their days looking at their computer (outside of email and reports anyway). What I have seen is how they've taken to me sitting in front of them during review sessions and making changes live, in front of their eyes, as they make suggestions. It has shortened the feedback cycle, making the team significantly more effective at our job. When I started this effort, I expected it would take months to complete just the 75 use cases I originally outlined. We've been at it for about a week now and have 25 ready for stakeholder review.

Lessons Learned

Having the right tool is invaluable. No, we're not using a structured requirements tool. No, we're not using rich prototypes. No, we're not using pixel-accurate renderings of screens. Yet, we're achieving astounding results for no other reason than we're collaborating in a way I have never done before. So far, only a subset of the team is working this way as well. What will happen when the larger group of BAs, our stakeholders and the development teams start using this as well? I can't even imagine the productivity gains that are yet to be recognized.

Collaboration, when facilitated by technology, is an enabler you can't understand until you have experienced it. Yes, it is still annoying when I have to output my wireframes to a image file and then import them into a MS Word document in order to share them with my stakeholders. That is still frustrating, yet being able to work in real time with my coworkers nearly makes up for it. My stakeholders only review a nearly complete work product; they don't care about the guts of how I get it done. If what used to take me weeks of struggle fighting with my tools and of outdated versions found in the hairball that is a networked shared drive are things of the past, that alone is a victory worth celebrating.

I'm sure someone reading this is saying, "That's great. My company implemented something to do this YEARS ago. Tell me something new." That's awesome for you; we all envy you and wish our organizations put such an emphasis on providing such great tools to us, but we don't work there and have to make due with what we have. BUT, if this post taught you anything, it should be that good tools are out there and they are just waiting for you to use them. Use Google Docs for collaboration one time and, minor formatting concerns aside, I bet you'll be like me and be even more loathe to open up MS Word.

Tracking Requirements with Control Charts

The previous posts in this series have built an argument that tries to show how a Business Analyst should be as responsible for project outcomes as anyone else, possibly more than anyone else when you consider the BA role as communicator and the facilitator of everyone's understanding of project requirements.

They key in this work is showing people how things are going to play out as the project progresses.  Will you stay on schedule? Will features be descoped from the final release?  How will everyone feel about the project when it's ended?

Now it’s time to get into a particular technique that you may be able to use.  The fundamentals of my proposed approach are to use the requirements traceability activity combined with control charts to monitor how stable requirements are over time, and to raise the alert early so you can take action.

As discussed, we already know requirements are going to change in some way or another. Our job is to anticipate the changes and to help our team mates manage the time, schedule, budget and quality constraints to deliver the best results possible within the available constraints.

And at the same time we have an opportunity to open a dialogue with our clients and customers about the issues we face as a team. Together, with our clients we can often find innovative ways to get more out of our limited resources. And in some cases, they’ll go to work on increasing budget and schedule for us.

We start this example by reacquainting you with the control chart. You track performance within controls.  Too high and there is a problem. Too low and there is a problem.

This applies to project scope.  You have a budget allocated to you and if you underspend significantly you have been sitting on funds that could have been spent elsewhere.  If you overspend... well we all know about that scenario.

Given that you know requirements are going to change over time, and that the resulting work effort will have to change, how can you going to use a control chart to help you out?  Simple.  Plot the planned set of requirements on a period by period basis.

(What period? Weekly, fortnightly, monthly, whatever works for you.)

Next up: Handling the variations.

23 May 2011

Requirements = Scope: Interlude

Some revision;

If Perceived Experience beast Expectations, then you are well on your way to success.

In the context of this discussion; Scope = Requirements, what does this mean?

A few posts back Shim asked me if I am really am saying a Business Analyst should be training project progress.  The answer is yes, in some cases.  If you are defining the project's outputs through a set of requirements statements, and you are invested in tracking their progress through the delivery cycle, then you are already doing this.

Let's just put it on the table for the project community that the BA is fully equipped and ready to take over.  Move aside project manager :)

Okay - some projects in some contexts.

The goal of this discussion is to challenge the status quo, and to share some techniques about how to improve project outcomes.

Yesterday my post was about expectations and perceptions.  Let's link this to the theme of Requirements = Scope.

As a Business Analyst, you have defined a set of requirements.  You have put a proposal to the stakeholder community and are now managing their expectations about what is coming through the pipeline.

How do you use the information available to you to delivery effective messages?  How do you ensure effective management of expectations and the flow on of project success?

22 May 2011

Success is...

Last post we discussed aspects of project success.  I wrapped up with the diagram above.

Success is how you make people's experience beat their expectations.  You might know this by another popular phrase; Under-promise and over-deliver.  Let’s take a look at the levers you can play with;

  1. Expectations
  2. Perceived Experience

You can set people’s expectations by communicating with them.  You have many tools to help you communicate effectively, and that's beyond the scope of this discussion.  I do want to note one important aspect of expectation management.

Whatever you say competes with a lifetime of history and experiences, and of course the nature of your personal relationship with the people you are communicating with. Unfortunately, facts don’t speak for themselves. The facts are competing with people's fears, hopes, misapprehensions, false assumptions and a whole lot of biases.

The more your stakeholders trust you the more they’ll listen to what you have to say, and the more their lifetime of accrued experiences will be held at bay.

And of course trust comes though empathy, and this is developed by communicating frequently with openness, and by being honest and truthful, even when it’s difficult to bring up hard issues.

Perceived experience
Perceived experience is of course made up of two components; the perception and the experience.   Naturally we will seek to be as “facts and evidence based” as possible when communicating with clients and stakeholders.  We need to do this to build trust.  The way we present and carry ourselves with clients, they way we model behavior and the way we interact are all important.

Primarily we are in the business of delivery, and the experience of the tangible products we produce is core to what we do. So, most importantly you build trust through delivery of product.

Secondly there is the nature of perception. Perception management is like a post facto expectations management exercise. Some people do this well, and others come off as con-men.  Don't be in-authentic.  Stick to who you are and think about the messages you want to send out.  Be coherent in the way you act and speak.

Lastly, when things aren't going well, it's an opportunity to test your character.  Develop the skill of effective communication to ready yourself for the tough days.  For example, bad news is better heard early so that something can be done about it.  Practice this technique early and often with minor things, and you'll be ready when the big things go wrong.

So, there is some commentary on under-promising and over-delivering.  It's a useful piece of knowledge.

21 May 2011

Defining Success for Business Analysts

Congratulations. Now we know we have incomplete, potentially (certainly?) changing requirements, and a lousy ability to estimate the work anyway.

“So what?” I hear you ask.

Remember that discussion we had earlier about how you are a lynchpin of project success?

Remember how we – together as an industry (not just analysts) are changing the world? No? You don't remember this bit?  Well, take it as given that we are part of a bigger picture and that we are - in fact - part of the human journey into the future.

You are right in the middle of all this planning and estimating. You need to help.

What do I mean by Success? Why are we even talking about project success when talking about requirements management?  Aren't there  too many other factors that come into play?  Yes, there are many factors that contribute to a team's ability to meet success criteria, but few people are in the position that the business analyst is to shape the discussion around what success looks like.

Some research was done recently and the researchers came up with some aspects to why projects are considered successful. Here is an abbreviated version their list. What ones are most important to your client? Which are important to you? Write down your top three for the work you are doing at the moment. And now write down why these three?

  • Budget compliance
  • Scope compliance
  • Schedule compliance
  • Quality compliance
  • Value generated
  • People learning from the process
  • Simply getting it finished

Now, whichever of these aspects you picked consider for a moment how they are defined in a measurable and tangible way. Think of all the work that is done to try to set people’s expectations about how much a project will cost, how quickly it can get done, and how it will revolutionise the company with the fancy new features you are bringing to them.

Ask yourself to what degree people are listening when you talk to them about the cost/risk/benefits trade-offs you are dealing with. How much of their expectation comes from the facts you present versus a combination of their past experiences and their fantasies.

For me, what is most important about managing for success is the relationship between what they expect, and what they get. Or even more precisely, how they perceive what they get.

It can even be described in a little diagram;

20 May 2011

How good are WE at estimating?!?

[Start at the beginning]

Personally I suck at estimating.  Estimating in the number 1 reason I feel stressed and pressured.  Bad estimated are, for me at least, the primary source of problems with customer satisfaction, and my personal satisfaction with my personal work in progress.

And honestly, at the project team level, estimates are so consistent bad, across so many teams that I wonder why we even bother with the pretense.  Even frequent feedback doesn't seem to overcome people's inherent bias for optimism or pessimism.

The one thing I know about estimates is that if they are met, it was most likely a co-incidence.

So just because you know the likely scope - which is what you planned, plus a factor for the quality of your outputs (related to available time, politics and a whole bunch of intangibles), plus your company's very own scope creep standards and the project estimated duration...

Well, even with all that, your estimates are likely to be crap.

Maybe, as a business analyst you can absolve yourself of the responsibility of tracing estimates to actuals and making corrections.

On the other hand, as a team member you are committed to project success or you aren't.

Which is it hombre?

What if our whole world view of project management is wrong, Redux

This is in response to a recent comment from Will on a 2008 post called "What if our whole world view of project management is wrong?"

There is a conversation going on among some of the agile thought leaders about replacing the project paradigm with product management.

If the world of software development shifts to many small projects (e.g. a week or two long) the 'unique endeavor' thing fades away and software development becomes operational.

The human side of projects - change management can also become operational by getting the business stakeholders to also adopt the cadence of small releases.

There is still plenty of room for project management - on things that really are unique and special.

But project management has been applied in many instances where it has been effective in resolving unmanaged chaos, but has in fact been the wrong solution for the problem.

FYI - Will pointed me to a new Dr Whitty post on Youtube. Always worth a watch.

19 May 2011

Reqline Beta Launched!

download1 You know, I have to hand it to the guys at Pragnalysis, they did something in a timeframe I didn't believe possible. Last Saturday, they debuted their new requirements management tool, Reqline. I love the idea of what they're trying to do here for a couple of reasons I feel I just need to point out.

First, the price is unbeatable. Its free. The last vendor I spoke with who promised me a revolution in how I elicit requirements wanted $250k just for a handful of user licenses. Their tool was, admittedly, top-notch, but when you work for an organization that relies almost exclusively on open source tools for their development practice, freeing up money for new desktops is hard, much less dropping a quarter of a million dollars, equivalent to some yearly departmental budgets, for a tool to replace MS Word, Excel and Visio, tools the company already pays a lot less for, is an impossibly hard sell.

Second, I like their approach. If you've been reading my posts for a while, you know I'm a big fan of simplicity. My general rule is to use as few tools as possible to complete the needed tasks in as efficient of a manner as possible. Despite the growing number of requirements management tools on the market, most try to be everything to everyone, and charge everyone for it. You know, I really don't need an absurdly complicated traceability matrix function, but if you just give me a list view with custom columns and, most importantly, an extremely fast way to enter the data I need, you're going to win me over.

All the praise aside, there are a few things that I have to talk about with the tool; things I just can't get over despite my want to love it.

Back to Reality

First up, this is a v1 release. Not all v1 releases are bad, but this one surely is. Guys, great effort, and I don't mean that in a pandering, elementary school soccer coach way. Please keep up the good work, but your tool, in its v1 incarnation, is simply unusable. Its not that I didn't try. I walked through the half dozen very needless configuration screens during the setup process and at the end, I was presented with a blank grid that did nothing. I figured I messed something up (user error, hello!) so I did it all over again. Same thing.

I'm a pretty savvy guy when it comes to software (just having to justify myself that way makes shivers run down my spine), but even I couldn't figure it out. I figured out Prototype Composer. I figured out iRise. I even figured out Oracle BPM Studio, yet your tool completely flummoxed me.

Maybe its not fair to pick on you, given I couldn't even get the tool to work. Maybe I should have contacted you for support. That's not really my point though. Its possible I was just over-thinking it and missed something very obvious, but isn't that in and of itself a problem? If I failed to be able to use it, what is going to happen to users with lesser abilities to navigate foreign software?

If I could give you only one piece of advice, it would be simplicity. Launch the app. Present 1 option for the user to fill out (the project name) and then slap in your 'best case' defaults for everything else. Get me using the app as fast as possible with as little work on my part as possible. Give me a way to tweak the settings later, after I get a chance to actually use it. Those half-dozen screens I walked through during setup? I had no context (other than my background as a BA) about the consequences of any of my selections, other than my experience with requirements in general. Keep it simple; it will help. There is a reason 'It just works' is a slogan. If it just works, you've solved most of my problems already.

But if I could give you a second piece of advice, it would be to ditch .Net completely. Its not a bad thing for desktop software, but its very limiting. You really want to do this right, you can still use .Net, but make this thing a web application that anyone can use. Don't make me install software; point me to your website and turn me lose. The name of the game for requirements elicitation and analysis is collaboration. Installing desktop software is a big bag of hurt on collaboration. Don't saddle yourself with what is a legacy application on its launch day. Don't tie yourself to something that can only be used on a Windows machine. Analysts need to be mobile and that excludes just about everything from Redmond, WA outside of lugging a laptop into someone's office.

Final Thoughts

It may seem like I was a bit overly critical of a v1 piece of software, but if you take anything away from what I've written, its that you shouldn't give up! Go on! Go faster! Go better! I love what you guys are trying to do and I truly want you to succeed beyond your wildest expectations. If you do succeed, then you've made my life so much better. I can't wait to see what v2 has in store.

How good are your requirements specifications?

[Start at the beginning]

A quick quiz for you:
  • Have you ever worked on a project where you've picked up requirements from someone else and they were incomplete?
  • Have you ever created requirements specifications but have really needed more time and more work to make them really - to your standards - good enough, but you simply ran out of time?
  • Have you ever worked on a project where the Sponsor, or some senior client has come up with a brilliant idea at the last minute? And the requirements suddenly changed radically?
  • Have you ever got stuck at a sign-off stage of a project, unable to get consensus?  To push things through you have to make compromises that create flaws in the logical model of the solution you were seeking?
I score 4/4 on that little quiz.

Requirements management in the real world is not as logical and delimited as you'd like it to be.  In defining requirements there are a number of intangible human factors that need to be accommodated.

The end result is that almost (always?) all the time requirements specifications are flawed.  They do not represent the true target model of the client.  They omit things, they include logical inconsistencies, they duplicate things, they emphasis things in a way that makes no sense to someone trying to build a solution.

There is certainly "good enough."  I have often developed specs that are good enough in days or only a few weeks.  Projects work well from good enough.  Possibly good enough is even better than the "high quality" requirements specification.

Good enough or not, requirements specs will not be sufficient tools to define project work on anything of scale.  Your understanding of requirements will change over time, and thus the work effort required to fulfill requirements will also change.

Did you know that someone has gone to the trouble of tracking the rate of scope change (creep) over time?  Did you know that the people/person who has done this shares his knowledge with the world relatively liberally?

You could (and should) buy the book Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies but the shortcut in this conversation is 2%.

Capers Jones in his research highlights that there is an industry standard scope growth of 2% PER MONTH.  That is quite a lot over a 12 month project (or program.)  Even more in 2-3 year projects.

Additionally you should consider that the group Capers has been surveying consider measurement of requirements growth a worthwhile activity and so are likely on the higher side of requirements management maturity.

What's your company's monthly scope change rate?

18 May 2011

Projects are not Programs

[Start at the beginning]
In the previous post you saw the natural flow of requirements definition to project scope definition.  The natural flow on from this idea is that the work required is naturally defined by requirements definition.  And that logically budgets and schedules should be able to be derived from requirements definitions.

I believe that this is true.  However there are some caveats.

THe first caveat is that many projects are actually multiple projects in disguise.  Remember that a project is an endeavor to create a unique product or service.  If you have multiple products being constructed within the one project framework then you are really running a program.  We'll deal with that another day.  Today I just want to share with you that despite what your local project management framework says, more than one product or service = program.

And that goes for the combined projects of building a software product and rolling out a business process change.  These are two distinct and discreet projects.  There may be dependencies, but they are two separate bodies of work with two different sets of measurable outcomes.

More caveats tomorrow.

17 May 2011

Event for Melbourne Business Analysts

David Joyce of Thoughtworks is leading a discussion on Process Mapping called "A Better Method for Improving the Work & Making Changes That Stick."

The abstract;
Traditional Process mapping that gathers people in a room to talk about how something works, rather than study from a knowledge creating point of view, produces little of value.
Process redesigns created by “experts” who then cascade their solutions to the workers simply creates resistance.
Many process improvement projects either end in failure, or don't stick, because we haven't tackled the thinking that created the problems in the first place.
I will discuss the need to reveal the thinking behind the current work design, and suggest a better method for introducing change. I will introduce an alternative method called Systems Thinking Process Mapping and show an example of its usage in one of the largest UK banks.
The event is Tuesday 7th June, 6pm.  It will be held in a CBD office.  You can get the details from the meet-up page here.

What do we mean by the words Requirements and Scope

[Start at the beginning]

Something I keep learning is that there is no one type of business analyst and no one way of doing things. So rather than come here and tell you how you should be doing your work I want to try to simply share some techniques I and others have used and leave it to you to work out whether and when it can be of use.

So, what am I going to share with you?  Today, I want to explain the relationship between requirements management and project scope management.

Let me start with some simple definitions to get us all understanding each other. Possibly you all know this, but bear with me for a moment or two. It’s useful to see how the ideas are related.

What is a requirement? It’s something we all intuitively know. It’s what is required by the customer right? Mandatory, must have it. It’s required because the client needs it to achieve some amazing business goal.
Good requirements management always starts with understanding the context and the purpose.

When asking people about their Business Requirements I like to start with understanding a client’s fundamental business model, or at least how the project fits into their strategy. It can be awkward sometimes, especially when the client doesn’t know themselves, but usually it yields more than it costs. So it’s a common practice of mine.

Understand the context.

And you all know about the various context levels of requirements; from business to system to the details within the system, like data requirements. So, there is no need to dwell on this too much.

Here are two industry definitions of what a requirement is:
  • When reading the BABOK Guide it is vital that ‘requirements’ be understood in the broadest possible sense. 
  • Requirements include but are not limited to past, present and future conditions or capabilities in an enterprise and descriptions of organisational structures, roles, processes, policies, rules and information systems (are all types of requirements.)
  • A condition or capability needed by a user to solve a problem or achieve an objective
  • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
  • A documented representation of a condition or capability as in (1) or (2)
That’s what we mean by requirement. The synonym is capability.

Now a definition of Scope. Scope is often defined up front in projects in a document, possibly with the title “Project Scope Document.”

Scope may also be addressed in other places like a “Project Charter”, a “Product Vision Statement” or other similar documents that get created in the opening stages of a project.

In some instances they may not be written down, but potentially captured in other media such as diagrams, video recordings and so on.

Here are the PMI Definitions for you;
Scope: The sum of the products, services, or results to be provided as a project.
Project scope: The work that must be performed to deliver a product, service or result with the specified features and functions
Product scope: The features and functions that characterise the product, service or result.
Scope creep: Adding features and functionality (project scope) without addressing the effects of time, costs and resources, or without customer approval
Thinking through this a little deeper, the main tool the PMI recommends to us to define scope is the WBS. We use this tool to break down the work - the requirements -  into organised components. Advanced instructions on developing a WBS talk about focusing on valuable deliverables at the top levels, and only breaking it down to activities and tasks only at lower levels of the structure.

Good WBS practice mens focusing on target capabilities, and then using this model to define the work.

And in case you are a Prince 2 Person; The OGC way addresses the issues of work planning slightly differently in technique and acronym, but in essence the same way. Prince2 instructs us to develop a Product Description (and elaborating it to a PBS) with a focus on the overall purpose of the project – how it will be used, or how it will contribute value, the components and features in the products, customer expectations on what done looks like, and the associated quality attributes.

Again, work is derived from what needs to be done to deliver target capabilities.

Fundamentally these project management approaches say that if you understand the requirements and you lead the way in understanding the project scope.

I'll break this down into a simple diagram tomorrow and share some examples of things that make the planning of work more complicated than simply saying the Requirements Specification = the Project Budget + Schedule.

16 May 2011

The Better Way I Wasn't Looking For

In the first half of this year, I've written a couple blog posts about the checkout line. Naturally, given that I've got two under my belt already, when I saw the below video about a future way to a better checkout experience, I had to share.

This said, I don't think the technology as presented (note that the upper right corner of the video shows how many times above normal speed they had to increase the video pace as to not put you to sleep) works very well, but robotics is a concept I didn't exactly explore in my prior posts.

Anyway, as you all start out the work week, I hope you enjoy the little detour into the checkout line!

15 May 2011

BA World Bangalore: Requirements Scope = Project Scope

My Presentation to BA World Bangalore is called Requirements Scope = Project Scope.  (I think) I'll be doing a similar presentation at PMOZ in Sydney at August.

Originally I had planned to do a presentation on how Control Charts can be used to improve the management of requirements. What I realised as I evolved what I wanted to say was that the concept was probably too advanced for the general analyst.

Many business analysts will be familiar with the idea of control charts. They are a standard part of the toolkit for people who work on process analysis and design. They are also a regular tool pulled out for Six Sigma projects. If you are a Business Analysts who came to the role via consulting or business process improvements you are likely to at least know the tool.

However, most people who have become Business Analysts have not worked on process analysis and have not used, let alone come cross the control chart when doing business. Additionally many analysts are very client focused and while we may use change management and process design tools for our client’s improvements we rarely turn them back on ourselves and assess how we can improve.

So my plan changed.

Now I simply want to focus on three key principles;

  1. Project scope is driven first and foremost by project requirements
  2. The Business Analyst, as the requirements manager, drives project scope and in the lynchpin role when it comes to project success
  3. There are tools and techniques that an analyst can use to manage requirements, and I’ll share one example (that is related to process control.)

Over the next few days I want to post the essence of my talk so that you can contribute to the discussion, and so the conference attendees can check in and see what the broader community think.

I hope you’ll help them by offering your thoughts in the comments.

11 May 2011

Seeking feedback on a Business Architecture model

Here is a problem I am struggling with, slightly removed and abstracted from a client I am working with.  I wonder if you could help.

I have categorized a number of existing business software applications according to the below list.  Think web publishing as a business context.

My challenge is that the list is not necessarily mutually exclusive or complete exhaustive (MECE.)  I am looking for your guidance on how to improve this list.  Can you help?  Does this list even need to be MECE?

  • Asset Management
  • Business Rules Management
  • Capacity Management
  • Configuration management
  • Content Capture
  • Content Creation
  • Content Management
  • Customer Management
  • Document Management
  • Financial Management
  • Identity Management
  • Incident Management
  • Knowledge Management
  • People Management
  • Problem/Opportunity Management
  • Project Management
  • Records Management
  • Release Management
  • Risk and Issue Management
  • Security Management
  • Service Management
  • Workflow Management

The idea here is that each of the above functions or capabilities should be supported by an IT system and business process. I have a description of each and can share it of you think it will help.  The descriptions highlight some of the relationships and areas of overlap - particularly between the areas in the CMS/publishing/KM zone.

RRR, The Triple-R

manage riskIf you're wondering why my blog post frequency has slowed way down as of late, I've been a bit busy at my day job as we start up a new program. This new effort will be multi-year and could quite possibly end up being the largest project the organization has ever undertaken. Its something we've been wanting to do for quite some time and now have the backing to go do. Its been a lot of fun as I've gotten to do two things I don't regularly get to do in this job.

The first thing I don't often get to do is create wireframes to facilitate requirements elicitation and process mapping. My love of visual design has expanded to a nearly absurd level over the past 3 years and I now find that there is little that gives me more fulfillment than using visual representations to flesh out requirements.

Second to wireframes is facilitating requirements elicitation sessions (using those previously mentioned wireframes). One of the 'trick's I've started doing is to intentionally provide my users with 'broken' wireframes. I give them something that has blatant holes to force them to say, "No, you've got that wrong! Take a piece from the first iteration, add in a part from the second one and slap them all on the layout of the third!" It is truly amazing how your stakeholders will figure out their own requirements just by being able to pick out your (unknowingly) 'bad designs'.

That's all good, you say, but what is this 'Triple R' thing in the title that you're not talking about. One of the things that makes the program I'm talking about so big is that there are many ways in which we could go about accomplishing the exact same goal. Different people within the organization, myself included, have our preferred methods. We all have sound reasons for why we think our path is the right one, most of which completely differ from anyone else's logic. Before we can get on with the work, we need to figure out what pieces of work we will do, in what order and with what technology stack.

In a meeting earlier this week, a subset team outlined 6 different alternatives that could be used to reach the same eventual goal. After we 'named' the different paths, we began to put together a list of items we need to create in order to provide a recommendation to senior management on what roadmap we'll be following to reach the goals we've been given.

We started with a list of Pros and Cons. We talked timelines, both for implementation of the first phase and project completion. Budgetary concerns were raised. Business and technical acumen was discussed. At the end, we had a list of areas that needed to be covered in our presentation, but as I looked at the list, I felt like something was missing. That's when it hit me, we were missing Risk.

Getting to the Cold, Hard Facts

Each of the six options we had outlined were risky. If you put them all on a scale of 0-100, all of them were 80+. What we're doing is risky and there is no way for it to be anything else. Given that the scope of the program will touch nearly everything in our organization, it will simply be a risky venture.

Yes, there are ways to minimize or shift away the risk. We create plans, we build contingencies and eventually we just have to accept some level of risk as being a part of the game. What concerned me is two things: what was the type of risk in each of the solutions and what are the risks that are not shared by all the options.

We know all about the different types of risk: business, technical, regulatory, financial; the list goes on and on. Each of those six solutions had different types of risk, but I wanted to know what type of risk, and the degree of risk, that is specific to one or more, but not all, of the options. Knowing this information allows us to boost the signal to noise ratio; helping our executive team focus on the actual risks within the solutions and not get stuck on the risks they can't change.

As I looked at each of the solutions, they really fell into a couple different types of risk. Some of the solutions were built on technology that has been proven out, so its technical risk is lower. Other solutions follow a build-in-pieces methodology and thus provide a significantly lower organization change risk. Some of the solutions rely, to a greater extent, on 3rd party software licenses and thus, pose a greater financial risk.

With the risk profile so high for each of the options, its important to not only find the types of risk, but to understand that risk is relative. That brings us to the 3 R's, or what I ended up calling the Relative Risk Rating. My suggestion to the group was to not try and minimize the risk rating on any of the options, but given them a rating in relation to each of the other options. Given that each of the options likely had an 80+ total rating, I was suggesting ratings such as High, Higher and Highest, with details next to those ratings about which groups in the organization would bear the largest risk burdens.

The team liked the idea and we're going to give it a try. We're just now started putting together the format, so we don't have a final look and feel for it all, but I can't wait to see what the team comes up with and how it ends up influencing the final decision.

What are some ways you have used to explain risk to your sponsors? Would the Triple-R work for your organization? Let us know in the comments!

7 May 2011

My BA World, Bangalore presentation

Wordle: Scope = Requirements

I just completed writing my talk for BA World Bangalore.  I'll be using some Wordle graphics in the presentation.  The one above is the whole speech pasted into Wordle.

Wordle: Agile manifesto

Here is the Agile Maifesto and below the DoD EVM guide.

Wordle: DoD EVM

Lastly, Six Honest Serving Men.

Wordle: 6 honest serving men

6 May 2011

The wrong business model?

I have been using an application to tether my laptop to my Android phone.  I am not using a native android function because it potentially doesn't exist, or if it does it's hidden and not easy to find.  Or I am stupid.  (I rate the last option as most likely.)

For a while the application worked great, then one day after an upgrade it no longer supported access to certain web pages.  Now I have to pay for what, for me at least, is a minimum value product feature - the ability to access webmail.  And there are many many more products on offer out there that don't charge for the same service

This is an implementation of the Freemium Business Model - where I get the basic product for free, and pay for more advanced features.

But this application is no longer a viable product for me.  I'll be replacing it with something else.  Free is no good if it doesn't hit a critical feature for me.
Andrew Chen and Eric Reis both have interesting thin gs to say abut this that preempt what I am about to say.  If you want a more in depth discussion from the point of view of the entrepreneurs and marketers who wrestle with this problem day to day.
What I have to say is simple;

As a customer in this instance I am probably not an outlier. Web-mail is a pretty fundamental feature for mobile workers.

So, on the one hand, this mandatory-ness makes it something people will pay for.  On the other hand it makes it a core part of the service, which - in the Freemium model - is supposed to be free.

When making the decision to charge or not charge for this aspect of the service what questions were asked? Were tests run on pilot groups (am I part of it?) and to what degree did the customer participate in the discussion.

Not enough probably.

How much are you including your customers in the discussions about how product should be formulated?  Is the answer the same?

4 May 2011

#AgileBA meet-up in Melbourne

Last night we had another Agile BA meet-up in Melbourne where Reg De Silva re-iterated a talk he delivered last year to the IIBA.

The key message: The BA, as requirements manager, is a lynch-pin role that is critical to the success f successful teams.

Why the BA? Well you should have come along to the meet-up to hear the details.  Or come along to the next and ask him yourself.

Details here.

3 May 2011

Its not what your Requirements do...

...but its what people do with your Requirements.

If you've been reading this blog for long now, you know that I'm an unabashed Apple fanboy (who also works with Linux and Windows at his day job, has a Chrome OS netbook, 2 Apple laptops, 2 iPhone 4s, a classic iPod and a 1G iPad). Given that, you probably won't be surprised at how much this article captured my attention. Its something I've believed for a while, that when a product is right, it can do amazing things in the hands of the most common (or even sub-par) user.

Why are requirements not the same? I remember, not so long ago, when I actually told one of my BAs that "You just start requirements by saying 'Have the ability to...' no matter the subject of the requirement." I think back on that and just want to slap my younger self in the side of the head for completely missing the point.

I can only imagine what it must have been like for my user community to read that document. (Come to think of it, that project got killed before it started, so its unlikely anyone ever read that document. Thankfully.) It was likely so dry that they decided War and Peace was a less painful, and shorter, read.

But in the right hands, dare I say the hands of a master requirements craftsman, your requirements can do amazing things for your stakeholders. The biggest thing quality requirements can do is to get your stakeholders to use them.

I've noticed that stakeholders seem to care about requirements at two points. First, when they are outlining their vision or problem to you, the analyst. Second, when they need someone to blame that their vision can't be accomplished or their problem isn't solved by the process and/or system that has been implemented. Part of this is because stakeholders often view requirements as a bothersome process that takes them away from their important work.

Imagine if we wrote our requirements not with system implementations in mind, but with the idea that they teach the business how to operate more effectively regardless of the software they use. Imagine if our requirements documents provided the basis for departmental policy and procedure and not just how we display text on a screen. And most crazy, what if our requirements could plot the future strategy of the organization and not just the layout of the new coversheet for your TPS reports.

So how do we get there? How do we help our stakeholders understand that what we do isn't a prelude to software but is a truly value-add part of their business? I don't know of any magic, but here's a few things I do to try and help.

First, make it about the relationship. Requirements are not a document, series of statements or a big set of process flows. Requirements define needs and wants of stakeholders. The only way to really understand and draw out those items are through relationships with our stakeholders. Its corny, but our stakeholders really don't care how much we know until they know how much we care. Take the time to get to know them as people and to let them know you as a person.

Second, make requirements something they want to review. I'm not suggesting lacing a document with 1 liners or even hiding 'easter eggs' with door prizes attached to see who really reads that 300 pound document. It doesn't need to read like a romance novel, but it does need to be read, comprehended and then become actionable by our stakeholders. We're told we should write to achieve clarity, but what does that mean? The dictionary is written for clarity but by no means do I want to sit down and read that!

It is easier said than done. Most of the time BAs sit between the business and the project team. We're trying to write with multiple audiences in mind. Creating one version of requirements in business-speak and another in tech-speak is a recipe for disaster. Creating one version for all purposes is nearly as bad. What our goal should be is a single, common lexicon that all members of the project speak, one that is specific and measurable enough for the programmers yet encompasses all the vagaries that make up our business people's lives.

This isn't easy; its a delicate balancing act that I have come to realize is something that can not really be taught but must be learned. I've been thinking about ways to teach this for years, yet continually come up empty when trying to show new BAs how to do this. No answer has yet presented itself, but with time I hope to find better ways and then share my insights with all of you.