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

During the Discovery phase, High-Level Requirements can be a fair way to ascertain your effectiveness. If stakeholders sign off on your High-Level Requirements, you know you are not totally missing the boat. It is a good way to make sure you don’t put too much effort into doing more detailed Requirements that are not accurate. It also helps you identify the “nice to have” Requirements versus the “must have” Requirements.

This is what they tell me. I dont believe it at all.

First, a Requirement is something that is required. If a Requirement needs to be removed from the scope of the project because of time, budget, or other constraints, it is cut. It does not fall away because it never really mattered all that much and was a “nice to have” to begin with. It was a Requirement. Now, it has been cut from the scope and methodically, deliberately, purposely removed from the list of Requirements. There is no such thing as a “nice to have” Requirement, although many folks who teach Requirements Analysis would have you believe that there are.

Requirements are required under the contextual scope. If they are removed from the scope, they are no longer Requirements.

Now, there may be reason to note which Requirements are more important than others so if it comes down to it, scope items can be removed with intelligence. You can cut an expensive scope item if you need to, and you can know that item A is mandatory and item B is mandatory but if need be, item B can wait. Or, while it is mandatory under the current scope, we can go back and manage stakeholder expectations, explaining why it has been removed while making it clear that it was a business decision, not arbitrary. Still, I maintain that our fated Item B is a System Requirement. It is required against the project baseline. We have simply adjusted the project baseline – and as you know, baselines adjust, shift, and change.

A shifting project baseline is normal. A non-required Requirement is not.

High-Level Requirements do very little good in and of themselves. While they are the PM/BA equivalent of sticking your toe in the water, you are going to have to swim. Talk to your stakeholders. You are supposed to be doing Discovery. There should be no need to stop at High-Level when the client wants their system documented, not their general intent. The Business Case will do enough towards that end. High-Level Requirements are, in a way, cowardly.

There is a major caveat here; when involving third party consultants, it may be very beneficial to have them draw up High-Level Requirements. Ideally, this would not be the case, but reality is that even the most well-respected consultants sometimes get it all wrong. What I object to is a *deliverable* consisting of High-Level Requirements that carries a price tag.

I know I may be alone in thinking this, but that’s okay. I simply do not see the point in wishy-washy Requirements and timid documentation. We are here to build systems and to earn our money. We are not here to create artificial deliverables or Requirements. Project Management and Business Analysis get a bad rap as it is. I cannot tell you how many IT professionals I have encountered that consider Project Management a pseudo-skill, a collection of soft skills, a discipline without metrics to gauge its efficiency.

PMs can be the people that make or break the simplest and the most ambitious projects. Act with Boldness. Roll your sleeves up and get involved in your projects.

A little venting, today.

System Requirements probably need to start at a High Level, but they are not worth much of anything until you drill down a bit. Functional Requirements at a High Level are just a collection of generalizations and broad swipes at meaning. Consultants and professionals have no business billing for the delivery of a High Level document. They can be called Roadmaps, Development Guides, or masquerade as Statements of Work that trap the client and provide the consultant with carte blanche. They are bad news and bad business, in my opinion. All too often they are “Get Out of Jail Free” cards for unsavory consultants. You sign off, because they are accurate, but then the consultant is only bound to the High Level. Big deal. They may not present you with anything else to sign off on besides the Statement of Work and Contract. Be sure you know what you have coming in regard to documentation. Documentation may be all you have to fall back on.

That said, if the MoSCoW approach is to be taken to heart, it should be a guideline and not a rule. In my opinion, as of today.

Best,

Josh Milane

MIT Technical, Boston

A friend of mine has a Client that is quite unique, and he is viewing it as a rare opportunity to see how different techniques in regard to software development resonate where there is no prejudice aside from repetition of what exists – and in this case, what exists is chaos. There are no processes in place, but knowing process, you can see where some of the pain points are before you even talk to the team members. The Client has product owners (without the title or formal role) tell project managers (who are really project coordinators) what they need – which is sometimes in sharp contrast to what the project or the end user needs. There is no analysis or discovery beyond note-taking. The project managers hold meetings and read their notes to the development team. Of course, a lot is lost in translation, and the features that need to be built are generally communicated in a way that leaves much to interpret. The developers go off, build what they think they are supposed to, and deliver it to some very unhappy stakeholders (who, even if the developers had nailed the original requirements, usually changed said requirements several dozen times since inception).

These are smart people who work for the Client. They simply have done what a lot of smallish business do: grow quickly and make whatever adjustments they need to in order to get the job done and the project out the door. Reuse, extensibility, etc., are not immediate concerns and documentation would be futile.

The first challenge – or the most obvious one – is positing team members so that their role is defined. For instance, the aforementioned product owner is only the product owner because they have veto power, and their nod grants. However, they do not carry the responsibilty of nodding, and they do not act as the decision maker until they are personally interested. Any member of the team who is of sufficient title can change a project direction without consideration to repercussions, timeline, budget, or scope and the project managers are left to try and figure it out. It is the absence of process. It is chaos. Now, over time most of these things land *somewhere* and the corporate culture sees that *somewhere* as the end result. That also has to change. It is obvious that a simple team structure with simple processes such as iterations, sign off on feature sets, prioritization, and empowering the product owner by involving them more instead of giving the illusion of power by allowing them to be removed would be helpful. And this is not even getting into the development process, which is in dire need of help.

Will update you as I interact with the team more and introduce some classic techniques as well as some more “edgy” techniques/methods. I suspect they are only edgy because they are not well established, but it will be interesting to see how a team devoid of PM education takes these different suggestions.

Until next time, thanks for reading.

Josh