A Couple Good Things About Having A Business Analysis Plan

Do you really need to have a business analysis plan for this project? You have been doing solid BA work for years and this project looks to be the typical wash-rinse-repeat variety. Here are a couple unconventional reasons why you might want to invest the time to build that often under appreciated document.

THE PR BUMP
A well written BA plan can be great PR and makes you look professional. When I was a junior developer, I was given some sage advice from a senior developer. It went something like this, "If you make it look easy, they will assume that all of it is easy". A BA plan can educate your stakeholders on what you do and encourage their support in your efforts.

If you are looking for a head start, I can share with you what I did, when I was in a pinch one time. I simply did a Google search for "business analysis plan in ms project" and came up with a wonderful template from the Austin Texas IIBA group. Here is the link and hopefully it will still work when you try to access it. 

http://austin.iiba.org/index.php/professional-development/template-library

Now, here is something that confuses a lot of people. A MS Project schedule is NOT a plan, it is a schedule of a plan. You will want to compliment your MS Project file with a MS Word document so that it can capture things that don't fit well in a MS Project file. For example, how a requirement change control process is handled.

CHANGE CONTROL PROCESS
Every time you get a stakeholder to actually use an established requirements change control process, it gets easier for everyone. The first time a stakeholder uses the change control process is always the hardest and contains some level of unnecessary drama. You can run a small project without a change control process, it is in the same general risk level as "texting" while driving.

You will get individuals that will want to bypass the change control process and most of them will have the title of Project Manager. They will often tell you they support a formal change control process and everyone should leverage it. Then a day will come where they are trying to get approval for something and someone threw in some previously uncommunicated request at the last minute. They will say something like, "We are on a tight deadline and this adjustment really doesn't impact the effort enough to execute change control." 

In fact, I can only think of one use case where a project manager is a strong advocate for requirement change control. This is when they want to kill a stakeholder change request and they want you to be the fall guy. Which is one reason why you might want to make the project manager the first approval sign off on all requirement change requests.

FYI... I love project managers, I really do!

Project managers are often the heart and soul of a project. When I say silly things like I did above, it is because I do appreciate them. The business analyst is often the first line of protection for a project and a project manager. Often times, that includes protecting them from themselves, when a project is shaking like a washing machine with an uneven load on the SPIN cycle.

©2015 Dwayne Wright