Business Analysis

Let’s talk about business analysis (not to be confused with business analytics, which is different).  Consider a SQL development project.  Defining it is a matter of answering three questions:  Why, what and how?  “Why” are you doing it is the business requirements, “what” are you doing is the logical and functional design, “how” you are doing it is the physical design and code.  If you think of those answers in a continuum from requirements to code, usually a systems analyst or technical PM is the one to provide those answers someplace short of “code”.  In Scrum, the answer to “why” is owned by the product owner, who provides and stack ranks requirements and accepts work products as meeting those requirements.

So what is business analysis?   PMI defines business analysis from the context of a project manager who works with stakeholders to enumerate project or business requirements, and ensures projects drive successful business outcomes.  The International Institute of Business Analysis™ (IIBA®) defines it more expansively.  Their definition is more encompassing, and probably closer to what used to be thought of as business consulting, a practice to achieve organizational improvement.  Rather than paraphrase, read IIBA’s description.

I really enjoy my time as a business consultant, but it seems to me that the reality for most organizations is PMI’s view of business analysis.  Companies are always trying to get “closer to the customer”, to better understand requirements and thereby efficiently produce products customers desire.  Even so, it’s also my feeling that there’s a lot of value in IIBA’s Business Analysis Body of Knowledge (BABOK®) and understanding it makes for better projects.  It’s no trick to say the more knowledge a project manager has, the better are the projects they manage.

Agile and Bending Over Backwards

Every been asked to do the impossible?  I remembered a troubled project I was brought into.  The prior manager had been relieved, and there was three months left on this project.  By “three months left”, I mean “this is completed or scrapped by July 15th.”   No pressure.

On that project, I didn’t use traditional project management or the waterfall method of development.  You know how waterfall goes, you gather requirements, then you design and write specifications, then you implement in code, then you validate your code, then you put into production and maintain… three YEARS later.  If the requirements change in those three years, well, you’re taking costly DCRs.  Or maybe just borked.   Remember the Standish Group’s Chaos Report?  Waterfall development is organized, predictable, serene, and stately.  The results can also completely miss the point (particularly if no real project manager is involved).

Enter “The Manifesto for Agile Programming”.  It was pretty new back then, and I had gone through a seminar on XP (Extreme Programming).  The premise of agile read like the Jedi Code:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

With two developers and a government-provided database administrator, we tackled the project.  It was quickly divided up into modules (Larry, Moe, Curly, Schemp and Joe), each programmer assigned to the areas they worked in best.  I worked the database side and interacted with the client, bringing work for acceptance daily and getting weekly signoff.  Did finish on the agreed time-frame?  Yes.  Was the customer ultimately satisfied?  Yes.  And, most importantly to me, did I get paid and also get an excellent reference?  Oh, yes.

It might not have turned out that way.  The resources were the same.  I had two great, if a little temperamental, coders.  We used  good system design practice, which is to say “loose coupling, well defined interfaces” and so on.  Lots of projects have those and still fail.  What was different was how we approached doing the project.  We eliminated overhead, white-boarded specifications, increased customer interaction and rapidly responded to change.  Every day, work products were shown to the customer; if something wasn’t right, it was fixed by the next day.  It was thrilling.  And terrifying.  And it worked.

These days, I find myself using Scrum a lot.  This is an overview.  This is the website of the creators.  Finally, if you were looking for Certified ScrumMaster® certification (which, a few years ago, you couldn’t get a development PM contract job without), head over to the Scrum Alliance.

Before I close, a couple of cautions.  I’ve seen plenty of development organizations declare “we’re agile!” and use that as an excuse to do what I call “water-fail.”  Huge, predictive and stately development projects on specific timetables that use NONE of the design practices of waterfall because “we’re agile!”  Meanwhile, sprints are multi-month long, communication is lacking, specifications are non-existent.  Don’t do water-fail.  And even if you avoid that trap, watch code velocity vs. stability and react appropriately.  You’ll thank me later.

North Star of Project Management

The point I knew I wanted to be in technology project management in college. I had attended a class in organization and environment, and they told us about the Polaris Missile Program. A process was developed by the US Navy, Program Evaluation and Review Technique, that enabled the program to manage complexity and deliver a project on time and budget. Wow! Of course, the Navy immediately applied their PERT process to the next program with, shall we say, sub-optimal results. That was interesting to me. There was more to the magic of getting things to turn out right.

The Project Management Institute (PMI®) has spent a lot of time coming up with project theory, learning materials and tools for project management. The Project Management Body of Knowledge (PMBOK®) is the result. By definition, what is a project? Well, it’s a time bound effort with a unique end result. That would make “designing a car” (a car design and relating tooling being the unique product, that process having a beginning and end) a project, but “assembling a car” (putting parts together in a factory resulting a daily production run) is operational work.

PMI has defined the framework as “Process Groups” and “Knowledge Areas”. Process groups is what you go through over the lifetime of the project, which is to say Initiating, Planning, Executing, Monitoring & Controlling, and Closing. Knowledge areas are project management processes required to ensure various areas of the project are coordinated, and they are Integration, Scope, Time, Cost, Quality, HR, Communication, Risk, Procurement and Stakeholder (new in the past couple of years!) management. These can be arranged in a grid, with process groups as columns and knowledge areas on rows. When I refer to project management, that’s the overall framework. We’ve come a long way from the simple view of a Scope/Time/Cost triangle, or as my general contractor is fond of saying, “You can have it good, fast or cheap — pick two!”

[Updated 6/16/2017]

Generally, I write, edit, add links and then double-check facts with searches (if I feel I need to).  Anyway, after publishing this, I searched for some project management links and decided that PMI wrote a better short article about what is project management.  If you search the internet, avoid the Wiki topic — particularly if you think you might someday take the PMP® exam.  If you want an interesting site of articles, I’ll suggest, which is sponsored by PMI, but there’s a lot of possibly overwhelming detail there.  If you want to go all sorcerer’s apprentice, in my opinion your best bet is the RMC book PMP® Exam Prep.  I suggest buying the most recent edition, but if you’re just using it for random study, a used older edition is fine.  Just realize that the knowledge areas are evolving over time.

Clarke and Conjuring!

Rather than being a project manager, wouldn’t you rather be a project magician? What if every project you did came out like magic? Tada!

Projects can run smoothly, like magic, but, like technology, there are a lot of things to know and understand.  Complex things behind the scenes are integrated to produce amazing experiences.

My wife and I used to have discussions that were sometimes punctuated by “that can’t be right”. One of us would say “The US had a plan to invade Canada after WWI” (turns out, we did). Once upon a time, you had to go to the library, or boot a computer, or otherwise figure out the answer. Now? Middle of the discussion, out comes a cell phone. BAM! There’s an answer. We go, “huh!” and keep talking. Cell phones have fundamentally changed the way we conduct conversations. And use maps, buy tickets, etc.

How does that technology magic happen? Well, the answer is “a lot of work and services under the covers”. For example, GPS, which involves satellites all around the globe. Each one of those services is very complex, requiring skill and resources to create. If you’re not in the industry, and just interested in sharing pictures of your dog, a cell phone is simply magic.

How do you learn to do project magic? Sorting the wheat from the chaff, or the magic from the dust, can be difficult. Sometimes you need a guide. What I will provide you is some tools and understandings across a variety of topics and linked articles, all things to add to your bag of tricks.

Let’s do some magic.