This blog was originally posted on my IIBA community blog on January 7, 2010.

Did no one at Microsoft consult a BA when they were creating the application Project? That sounds like an inflammatory and possibly even sarcastic statement, but if you’re like me, a BA who spends some of his time doing PM tasks, you really do begin to wonder. I catch myself thinking about how I might have structured the requirements for the Project product and can’t help but wonder how it got from the drawing board to where it is now. I do not understand, when I stare Project, why its two most heavily used views, task entry and the network diagram, became the basis for this application.

Project, a fairy tale

I can see the conference room from which it spawned pass before my sleeping eyes. The harsh, florescent glow of overhead lighting bathing pasty-skinned PMs in its unearthly radiance. The faint chemical smell of Sharpies used to chart out requirements permeates the air. But something from the room is missing, something vital, yet overlooked by all the subject matter experts in the room.

Half the room spends time talking about how they use Excel to create their project plans and now this new ‘Project’ program should do it the same way. The others talk about their stack of sticky notes and how a network diagram is how they work. Back and forth go the two arguments, each side’s argument ebbing and flowing as the days rush by. A settlement is never reached, but a compromise solution is selected, leaving no one happy and everyone vaguely unfulfilled.

Months go by as the coders are locked in a converted conference room, pounding away at their keyboards to the timing of the harsh PM whips cracking overhead.

“More speed! Our deadline looms!” screech the PMs running the project!

And lo, it is done. The earth shakes with the rumble of server fans as the final build takes shape. The compiler chugs and churns, crunching down code into a usable runtime. And with much rejoicing, Project v1.0 is born.

…and is promptly hated by all BAs who encounter it.

The PMs reconvene in their conference room. This problem cannot remain; it must be resolved. The arguments preceding v1.0 are rehashed and retold, wheels once again spinning. No quarter is given, but a halving was a definite solution.

Instead of scrapping two bad ideas, a list of tasks and a network diagram, the two were combined into a single view and Project 2.0 is released. Now, instead of two views which did only half the needed work, we have a single view, left half list and right half a Gantt chart, which has so much information at once that no sane monitor can display it all without scrolling.

…and is promptly hated by all BAs who encounter it.

Whimsical? Absolutely. Fantastical? Probably. Truthful? Ouch, definitely.


Its not that the idea of Project pains us BAs, as we understand the need to track our progress and have a plan for the work. The tracking functions of Project, when configured by a knowledgeable user, are rather good. It is the initial creation of a project plan that is such a chore we dread. Is there any other application known to man that hurts a BA more?

At the root of putting together a project plan is a specific set of tasks needed to reach a goal. Lets start by breaking out the tasks in putting together a project plan:

  1. Create the task list. A task, at its core, is work that needs to be completed. Project management courses can provide hints and tricks for naming tasks, but all Project gives a blank text field to hold this information? Don’t get me wrong, I’m not asking for grammar correction to be added to Project (I still have nightmares about the 'passive voice’ warnings from the 1990’s version of Word), but couldn’t we find a way to do this that makes the task more useful? Many tasks in the software development realm look something like, “Code such and such screen” or “Document Process Plumbob’. Why do we not have task types? Sure, there are custom fields that could be of use in this, but why does Project not have this or at least the ability to Tag a task? Even more useful would be something similar to creating a Google Calendar entry, where the information entered in the calendar entry description was intelligently parsed into the correct metadata fields.
  2. Assign an activity manager. This is where I, as a BA, step up and explain that collaboration is extremely undervalued and underutilized by modern business. When I attend a Work Breakdown Session (WBS), I invariably have a set of tasks that flow through almost every project in which I am involved. Despite this, I find myself dragging out my WBS sticky note pad, filling out a list of tasks that are exactly the same as the ones I put together for my last WBS two days ago. Having everyone in a room to create the initial plan is wonderful, but sessions that take all day to complete could be expedited if only we had a way to take the tasks which we already know and pre-populate them into the plan. At this point, someone is going to mention Project Server, to which I must retort the limitations in place that stop more than one person being able to add tasks to a plan. I don’t want to send my tasks in a small project plan to the PM for them to enter, I want my standard tasks to be able to be pushed into a new plan. If my tasks have dependencies upon someone else’s tasks in an existing plan, Project should be smart enough to see if those same tasks are also in the new plan and prompt me if they still apply.
  3. Add a resource. I don’t really have a lot to say about this one as the combination of Project and Project Server get this one right. A single list of all resources, that is sorted alphabetically and can use quick-key shortcuts to jump through the list is great.
  4. Add dependencies. This is by far the most arduous step in setting up a project plan because it functions in direct opposition to the way our brains seem to function. The idea of predecessors and successors is to show a relationship between two different tasks, but the way that relationship is shown is a set of line numbers that have nothing to do with the actual tasks. If I insert a new task between the two tasks I have related, the task further down the list increments and the numbers representing the relationship have changed. The numbers themselves are meaningless, yet they are the one thing that ties together our entire plan.

To sum up, the problem with Project is two-fold:
  • The task entry view is not an optimal way to really understand dependencies. Using task numbers to link predecessors and successors is inefficient and difficult to visualize. Network diagrams composed of post-it notes work amazingly well laying out the dependencies within a plan as it 'shows’ instead of 'tells’.
  • The network diagram shows the relationship between tasks, and when plotted with a timeline in the background, gives a decent approximation of project duration. This matches up with our sticky notes, yet in Project, there is no way to add new tasks in this view. I can read, but I sure can’t write.

Come Together, Right Now

It happens to the best BAs at one time or another. A project starts and no one has any idea what needs to be done to get the show rolling. Invariably a PM utters the words, "Lets see if the BAs have any ideas.” So, we find ourselves facing a room full of people who are discussing a subject about which we know nothing and are then expected to piece it all together into a workable framework.

We spend a few days talking with stakeholders, reviewing the documentation that has been compiled by the business areas and listening to the needs of the customers. The developers of the existing application, if there is one, tell us the history of that application and why its good or why it needs help. All of that information is cataloged in our brains and ready for use.

Now that we have our head wrapped around the task before us, its time to start figuring out how long its going to take to get all the work done. We pull together a team and then realize the PM is too busy to actually enter that task list themselves. Our hands shake as we move the mouse to click the icon to start MS Project.

This is why a BA is necessary for a major project undertaking. The PMs worry about the schedule, about the budget and making sure the sponsors are happy, but the output of the project itself still fails even if all of those areas work out flawlessly.

So how would I fix it? What would I have done differently? I’m glad you asked. I would take a tool that is the BA’s sometime friend, sometime foe, and create the most Frankenstein application you have ever seen. I would take the best aspects of Visio and pair them with Project.

Imagine the following sequence:
  1. The task list entry isn’t a bad thing, its just cluttered. Task #, Description, Activity Manager, Resources, Duration, Effort and many more columns make entry difficult, especially when you try to add in predecessors and successors at the same time. Make a task creation list view on the left side of the screen with just three fields: Description, Duration and Activity Manager.
  2. The rest of the screen is a very Visio-like drawing pad. Once the tasks are entered in the side pane, they can be dragged and dropped into the diagram area, just like a Visio task.
  3. Drag a task over into the Visio-like area and it disappears from the list of unused tasks.
  4. Grab a second task and drag it on to the diagram area. Lets assume that task 1 and task 2 have a finish to start relationship. Drag the left edge of task 2 onto the right edge of task 1. Project now understands that task 1 is a predecessor to task 2 and makes the appropriate link.
  5. Keep adding more tasks to the diagram. But wait, there are more types of relationships than just finish to start! This is where the genius (if I do say so myself) comes in to play. Need a Finish to Finish relationship, grab task 3 and bump its top line into the bottom line of task 1. Start to Start, grab task 4 and bump its bottom line into the top line of task 1. Start to Finish, grab task 5 and bump its right edge into the left edge of task 1.
  6. What if you mess up? How do you break a relationship? Simple, click the relationship line and press delete. If one of the tasks (or both) are now unassociated, they slide back into the list of unassociated tasks or just hang out on the screen, waiting for you to make a new association for them.

Once my tasks are all entered, I now have a third view which already exists in Project, Tasks by Activity Manager. The activity manager looks down their list and assigns level of effort and resources accordingly.

…and my project plan is done. I baseline it and dive in to completing the work I just outlined. There, now wasn’t that easy? To borrow a phrase from Apple, it just works.

Can you come up with a way it might work even better?