Blog of a Boston-based IT Consultant

Until I started looking for work as a Project Manager years ago, I did not know what a Business Analyst was. I knew the title existed, but I couldnt have explained to you what they actually did. I existed in happy ignorance regarding this subject for some time. Through the years, I found out that there actually was something called a Business Analyst, and that they did what I did as a Project Manager, only on a finer scale and better than I did it.

This is of course, erroneous. There is a lot of confusion out there as to what a Project Manager does as opposed to a Business Analyst - and if not confusion, overlap. While at larger companies and more well-defined organizations you might have a BA and a PM who are not the same person, many smaller companies and companies with less IT staffing infrastructure call this person the Project Manager and nobody knows that they are not, strictly, a PM. Well, I guess they are a PM, just a multifunctional PM. Anyhow, typical tasks that you will see on the plate of a PM (that are really BA tasks) may include:

1. Requirements Documentation, particularly Business Cases and Functional Requirements Documentation is really a task for a Business Analyst. In your smaller companies, you still have projects with requirements, but the projects themselves are less likely to call for a full-time BA. So, the PM winds up doing the work. I never minded. In fact, knowing how to use UML is a great way to impress people really quickly and establish that you know what you are doing (even if you don’t). UML is a fantastic language to know anyhow. I find myself making Sequence Diagrams of my wedding ceremony. Really. I am that ridiculous.

2. Managing the Traceability Matrix. It makes sense that a PM who is watching a project from Inception to Deployment would make sure that the Requirements are monitored closely, but the Business Analyst who originally defined the Requirements is the one who should ideally be following a line of continuity from Requirements to Testing. If a small company is lucky enough to have a PM who has created a Traceability Matrix and keeps it up to date, they are lucky as can be and need to make sure that their employee is getting rest, because they are taking on a lot of work by choice. I always had a Traceability Matrix because I was scared to death that my projects would fail. It seemed a great way to make sure that at the very least, what the stakeholders signed off on is what they got. Early in my career, 8 or so years ago when I first used Traceability Matrices, a thorough Traceability Matrix was my peronsal measure of success. Now, that measure has changed. It does, however, mean that the project was managed from Requirements to Deployment.

3. Business Use Cases. A lot of you are giving me a “duh” right now, but believe me; there are a lot of organizations that rely on their Project Managers to draw up their Business Use Cases. Who else is going to do it?

I am thankful that I was not clear as to the delineation between a BA and a PM until a few years into my career. I learned a heck of a lot that can be useful and coming from a Development background, the BA tasks actually made transitioning to Project Management much more sensible.

If I am a PM looking at a bunch of WBS entities, I can assign resources, budget, figure out the Critical Path, and do all kinds of management-based activities. If I have BA knowledge behind my PM knowledge, I might know how likely it is that a specific item will actually take 21 hours to do and that really, it could be combined with another item to yield a piece of functionality that is more effective, extensible, and robust than the two functions alone. Sometimes it is easier to build something generic and deploy it in instances than to build disparate, specialized objects.

The .NET library, Joomla! CMS, and other development/deployment tools give Developers a ton of really cool functionality that is almost as simple as drag and drop. A PM with BA background, working in information technology, can become educated in the functionality within development tools and proactively leverage them towards the Solution they want to build. I am not sure this is the best thing to do, always, but it can be done and is certainly helpful to a small organization with a small IT staff and limited timeline or budget. Really, any side of the Triple Constraint triangle can be shortened by a good BA/PM with some technical knowledge. It isnt always immediately apparent, however, where the solution is forcing an interpretation of the issue at hand.

Very recently, I began work on a SharePoint 2007 (MOSS) project. MOSS was being customized for the project before the Requirements were done. The PM in me did not like that at all, but the BA in me found real value in picking a tool and utilizing the OOTB features that it offers. While I do not believe that Design can *ever* come before Discovery, a good BA/PM can be aware of what the Business Needs are and visualize a roadmap towards delivery that is based upon the software package’s native abilities and makes the project itself easier to estimate in terms of time and cost.

There is overlap, and I am aware that there is a difference between a Business Analyst and a Project Manager, but I believe that the delineation should only exist where it is of obvious benefit. Otherwise, you have more communication overhead and a host of other issues that come into play with team management.

I am glad I learned the hard way. If you are a PM doing BA things, you’re lucky… and valuable.

And tired, I bet.

Best,

Josh Milane

MIT Technical, Boston

Project Management | RSS 2.0 | Comment it , or trackback this post.