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