Project Management

Should A Business Analyst Know How To Build Robust Project Schedules?

The requirements life cycle is directly tied to the project life cycle, there really isn't any way around that reality. If a project is not planned well, you can expect the impact to be felt in requirements gathering, requirements analysis, requirements validation and requirement change management. This could be one of the reasons why you see a significant rise in job opportunities that are titled Business Analyst / Project Manager. 

Came across this amazing bike sculpture on the Green River Trail! Took the opportunity for a "selfie" that looks like I'm riding with them!

Although many successful business analysts do not know their way around project scheduling tools such as Microsoft Project, I find that skill set very useful. In one project I worked on, the project manager built a MS Project schedule that clearly missed the mark in the requirement management area. That entire section literally didn't have one requirement task that was listed as a predecessor to downstream tasks or milestones. This was a circumstance in which I had to fight for my requirements schedule without being confrontational or combative. 

I believe that every business analyst should have a requirements management plan and work to have it submitted into the project documentation portfolio. That plan may or may not include a schedule, my strong recommendation is that it should. In the situation described above, I did the following:

- built a MS Project schedule for the requirement life cycle tasks
- rebuilt the project managers project schedule to include the above content
- setup each requirement task as a predecessor task where appropriate
- estimated the duration of requirement tasks with a goal to align with overall schedule objectives
- used color highlighting to show the critical path tasks as they pertained to requirements
- scheduled a workshop with the project manager to go over the content
- used a structured walkthrough method to go over my recommendations

I was very careful in my approach during the one-on-one workshop with the project manager. I had a high level of respect for her and didn’t want her to take my feedback as a challenge. Project managers have a tough job and my goal was to be a valuable resource for the project. Although I obviously felt a strong commitment to my feedback, I was prepared to defer and commit to the chosen path as a project professional.

This project manager was and continues to be an exceptional PM. She did incorporate many of my recommendations but that wasn't the most important thing she did. She scheduled another workshop with key team members and we went over it again. This opened up a valuable discussion and the team bonded a bit tighter that day. The schedules I created became a great way for the team as a whole to understand the requirements lifecycle and it paid valuable dividends as we marched towards a successful project completion. 

This is just one story and I hope it may have provided some insights for you. I welcome any comments you may have both positive and negative. 


© 2016 Dwayne Wright

Competing Expectations: The Project Manager & Business Analyst

The role of the business analyst is on the rise and often encroaches upon areas traditionally within the project managers domain. Although this conflict is actualized between those two roles, the root cause is generally found higher up in the organization chart. Both project managers and business analysts work very hard to meet the expectations of their superiors. Often it is the competing expectations that are causing the conflict and not a personality clash between the two roles.

When an organization places a project manager within a project, they are expecting that individual to deliver within the established budget and schedule. Simply put, project managers will manage scope creep because it is a legitimate threat to schedule and budget. A project manager that delivers a project within budget/schedule constraints with additional scope included is generally considered a great project manager. Yes, there are exceptions to this but not that many! In fact, unless that extra scope that gets squeezed into the project introduces new company risk, that project manager might expect a promotion for delivering more for less than expected.

A business analyst is expected to deliver significant value after the project closes. They identify areas in which more revenue can be returned or less costs incurred based upon value multipliers. A value multiplier would be the number of times the value can be triggered and the value amount. For example, a new feature saves an individual 2 minutes per use, it is used by 10,000 people at an average of twice per week. Exploring the value math, 

• triggered 20,000 per week (10,000 people x twice a week)
• 1,040,000 minutes per year (20,000 x 52 weeks)
• 17,300 hours per year (1,040,000 / 60)
• 70,000 average salary = $35 a hour
• $605,500 value annually (17,300 x 35)

The next steps a BA would perform include determining the costs of the new feature, perform a cost benefit analysis and associated payback period calculation.

If a business analyst wants to include an out of scope requirement in their package, it is because they feel the downstream value greatly exceeds the additional cost and project schedule impact. When a business analyst wants to submit a scope change request, the first obstacle they have to overcome is the project manager. Although a project manager should not have the authority to deny a change request submission, many will make the attempt to do so. They certainly should have a voice in the approval and I would recommend that all business analysts strive to have PM approval before submitting the request.  

The key to avoiding or resolving this fundamental expectation gap is knowledge. At the fundamental layer, a project manager should not look at scope increase supported by the business analyst as a threat. In fact, any project that doesn't undergo some scope modification is generally an unhealthy anomaly. This is particularly true in software projects but it holds true for all projects. If a project looks to be adhering tightly to the scope identified in the early business case / charter documentation, then it is likely that dozens of a significant value opportunities are being lost. 

© 2016 Dwayne Wright

A Different Take On Gamification And Project Management

Back in 2010, I took a three month job with Wizards Of Coast and that turned into a three year journey. If you are not familiar with the company, they make the popular Dungeons And Dragons role playing game and the insanely popular Magic, The Gathering collector card game. I was hired to help update a database tool that transformed editorial content about mystical worlds into components to support a subscription based online resource for serious gamers. 

Pulled this from their website in the about page. It was taken back in 2013 and I'm in there, can you find me? 

Basically, Dungeons & Dragons is a weird hybrid of story telling and group game play. The storyteller, called a Dungeon Master, facilitates the game play by unfolding the story as players take turns. Based upon decisions made by players, the roll of dice and sometimes a flip of a card, both the story and the game can branch into different directions. 

So the group of characters which the players have created bring unique skills to the effort. Additionally, each has a set of tools they start off with and tools they pick up along the way. They set off on a quest and have to coordinate efforts, communicate effectively and use problem solving skills to survive. Many times, the quest is actually a series of individual efforts that can span days, weeks or even months. Many times the players are prepared for the unfortunate events that unfold and sometimes they are not. Sometimes you loose characters along the way and that is considered unfortunate and can seriously affect the overall effort. 

Are you getting it yet? No, not the premise behind D&D. The project management angle in regards to this narrative, are you getting it?

Quest = Project
Characters = Team Members
Decisions/Dice/Cards = Decisions/Outside Factors
Magical Characters = Team Member Skills That Look Like Magic
Magical Tools = Software Tools
Coordination/Communication/Problem Solving = Coordination/Communication/Problem Solving
Unfortunate Loss Of Team Members = Unfortunate Loss Of Team Members 

When I was first introduced to the game during my first week, I had an odd feeling that I had played this game before!

More Of A Mindset Than A Particular Skill

For me, many of the skills you see listed for business analyst jobs are more about that persons mindset than it is about the skill. Many hiring managers simply do not understand this concept because they think that years of experience at one thing is more valuable than the persons ability to adapt. 

For example, they might be interviewing two candidates for a business analyst position associated with a large online travel agency. One candidate has been working in that industry for 5 years on a large project that was eventually scrubbed. The other candidate has worked for three different consulting agencies in the last 5 years. None of the projects in that time frame were travel related but all were closed successfully. You might not be surprised if the first candidate gets the position because they are considered more experienced.

Most quality business analysts will look at the problem(s) presented before them, consider a framework that might match the scope and begin planning the processes that will be applied to meet the goal. This applies equally to both the skills they currently have and the ones they don't. 

For example, a business analyst might explore Six Sigma as a way to meet internal continuous improvement goals. They learn about the SIPOC method, find it interesting but don't have any current activities to apply it towards. Then months or years later, they see the perfect application for it. 

From their mindset, they will likely google SIPOC and get some refresher information from articles and videos. Then they begin to apply the SIPOC method in private on some of their internal deliverables. Feeling good about it, they decide to give it a go in a stakeholder workshop for requirements gathering. 

It is true that doing a thing many times will have some incremental value over doing it a few times. However, there is a threshold when you don't learn much more about a thing just because you have done it two dozen times instead of a dozen times.

So the most valuable skill to have is more of an attitude about adapting to the situation at hand. Even though you have no idea how you are going to do it now, you are confident that you will be able to find a way to conquer those challenges that seem to be overflowing with uncertainty and risk.