Project Management in Real Life

Job Shadowing in the Project Initiation Phase will provide a good view of a day in the life of a department. Business Analysts use job shadowing to gather requirements and document the workflow processes. You don't have to be a Business Analyst to job shadow; project team members need to wear many hats at times. 

Process Improvement is the goal of job shadowing when you are replacing a system. Information that is collected from job shadowing will be used to compile your project requirements to achieve the defined deliverables. This is also a good time to start defining Key Performance Indicators that will be used to validate that process improvement is being achieved. Start making notes on Test Cases that will be used to validate the KPIs.

The Project Plan should have the defined KPIs evaluated at the appropriate time in the project timeline when results can be measured in a controlled environment. If all KPIs meet expectations, then a project Milestone is truly earned. If KPIs do not meet the expectations, then it's time to stop moving forward on the project so an evaluation can be done to address the failing KPIs. That's why you need good Test Cases to flush out any possible issues. 

My Final Thoughts on Job Shadowing that is a valuable project activity that should be used as much as possible to avoid disappointed Stakeholders after a project is delivered and it cosmetically looks good, but that's it, no improvement achieved. 

The Project Team Members is an important risk on a Risk Register, there are many other risks to add to the register, but my focus on this article is Team Members. 

Project Managers need to focus up front on the availability of team members for a project. The Risk Register should include team members working on different projects, especially concurrent projects. We often assign key staff to multiple projects which is fine if their key dates and implementation have breathing room for safe multitasking. 

The Risk Register will provide valuable insight into how your project team is spread out. The reprioritizing of project dates might be needed to address overallocated staff. It's good to know up front that you are working with overallocated staff so you know the potential risk that could be a showstopper.

Roll the dice or play it safe. Just make sure that management understands all the risks that are involved with overallocated staff. 

The big day is here to present a proposed project to stakeholders. You prepared a slideshow to provide visual aids so you make a clear presentation. Looks like you are well prepared for this presentation.

I have been to two presentations that blew up with displeased stakeholders. 

Presentation of a proposed cell phone tower in a residential community. It was presented at a neighborhood board meeting. The Project Coordinator started the slideshow and fielded questions that could not be answered. The Project Coordinator started to get nervous and stopped the slideshow and kept dodging all questions from the angry stakeholders. The chairman of the board had to jump in to address the Project Coordinator, he said can you provide the answers? He could not. The presentation was a failure. The Project Coordinator was not sincere to say I will get back to you on that question and just kept on presenting without being able to answer any questions.

Presentation of a proposed major neighborhood road work improvement project at a community town hall meeting. This presentation was slick and well prepared, but it ended in the community disapproving of it. The Project Managers did not crack under fire from the community. They kept their composure. Why did their presentation fail? They did not do a good job collecting traffic data and community input for the presentation. I call the examples they gave cherry picking and the community knew that they were cherry picking. 

Lessons to be learned from the two failed presentations.

1) Have subject matter experts available to help you field questions that you cannot properly answer. You need to anticipate the questions of the stakeholders in advance so you need to be well prepared. It's just common sense.

2) You think you have a polished presentation that will wow the stakeholders. Make sure you have accurate data to support your presentation.

You have created a meticulous Work Breakdown Structure of all the tasks for your project. The next step is to transfer that WBS to your MS Project plan. You created a very impressive project plan with over 10,000 entries. All you have to do now is maintain the plan to keep it fresh.

Are you kidding? The project scope has changed. My project plan has over 10,000 entries with start dates and finish dates. My masterpiece is ruined! I spent one month creating that project plan after the official sign off on the project.

Take a deep breath. All you have to do now is create as many as needed MS Project plans to address the additional scope. For example, you can create five small MS Project plans to address the additional scope.

Great, I now have six plans to maintain for the same project. Yes, you have six projects, but you can turn those scope creepers into subprojects by creating five tasks in your master project at the appropriate areas in the project plan. MS Project can insert a project into a project, resulting in subprojects in the master project.

When you bring up your master project all the subprojects will be there creating an illusion of one MS Project plan. Well, there will be a MS Project icon next to the line number in the MS Project master plan indicating a linked project. The subproject line numbers will start with a 1 - 97 for example, they do not renumber the master project plan.

A suggestion for large projects. Create a master project and subprojects to help make the management of the plan a pleasant experience. As much as possible we diligently gather the project requirements to build a project plan that will have minimal additions, but we need to respond quickly to incorporate the additional requirements that get approved and needs to be incorporated into the master project plan.

There is a plus to the birth of subprojects. From a reporting standpoint, you can show how much additional effort was introduced into the original project. You can create reports from the subprojects and of course, you can create reports of the master project with all the subprojects that are linked to it giving you the big picture.

When you are disciplined to create a master MS Project plan that employs subprojects, you gain flexibility in the master plan. You now have an Agile project plan to address the things that go bump in the night from those sponsors and stakeholders.

The dilemma of Waterfall or Agile.

Organizations should never declare that they are leaving Waterfall to be a full Agile organization. In defense of Agile you can't remain only on Waterfall. The problem is the lack of education and false perception. Education will help to get everyone on the same page. It's all about having clarity in the perception of Waterfall and Agile.

I can't make up my mind so let's flip a coin.

Waterfall is here to stay and it needs to play nicely with Agile. Opposites attract. Agile and Waterfall make a nice hybrid. The rule of thumb is to use what will work best to deliver project results. Did a stakeholder or sponsor ever ask you what approach did you use on the project? I don't think so. The stakeholder or sponsor could care less. It's all about guiding the team efficiently through the project to make happy stakeholders and sponsors with a project delivered on-time.

The Waterfall-Agile hybrid marriage.

The ship needs to raise the anchor and leave the harbor to make it to it's port of call on time. Many projects still follow a linear path to the finish line, but they have requirements not fully designed or approved. With tight deadlines you can't wait till the requirements dust settles to start the project. Use the approved requirements that you have to create a project plan timeline. Mark the the areas in the project plan timeline that are still waiting for the requirements dust to settle with a "Under Construction - Come Back Later" notation, hint hint, that is an example of Agile in the plan. The Project Manager is the Captain of the ship that will use his/her discretion to direct the team aka the crew on what needs to be done. The project plan timeline is the map to the destination.

They love colors, stats, and no budget variance.

The Project Sponsor is not interested in a dog and pony show. Using Waterfall in the plan will help give the sponsors that warm and fuzzy simple report card. What is the color of the project via Stoplight reporting along with the current project completion percentage. Hey look Mom no budget variance to report.