Microsoft Project

Avoid Project Crashes: File a Flight Plan First!

Posted on November 3, 2022November 3, 2022 by daniela

Avoid Project Crashes:

File a Flight Plan First!

By Jigs Gaton, PM / Pilot

First, let's step back 30,000 feet

We all know the drill as we start projects: pick or subserve to some PM methodology, gather your resources, erect lines of communication, etc. Agile, Waterfall, Bootcamp, Basecamp, whatever, we always begin there. But what if we are starting our projects on a wayward waypoint in the first place?

So, let's step back and look at this hypothesis; perhaps some of our projects might be crashing because our planning always starts in the wrong place. Think of this through a pilot's eyes, who instinctively knows you don't start a mission in the middle of the air... no, you always begin working far earlier than that, on the ground, even with a pre-plan for any take-off.

Continuing this analogy, in a pilot's pre-plan for the mission (think of every project as a mission), the pilot has a checklist shared between the pilot and co-pilot, and then portions are shared with the entire crew.

This project planning metaphor should be familiar if you are a PM with any experience; you are starting a new project, collecting a team, and strategizing what to do in the days (or flights) ahead.

(If not, see this article that compares pilots to project managers.)

So, let's dive into the idea of Flight Planning and compare that with what we all do when planning projects.

Where does Mission Project begin?

Sure, you might think a project begins with setting objectives, defining scopes, and clarifying goals. But in reality, these are just words to help us off the literal project runway, and truth be told, any Mission Project starts well ahead of all these fine activities.

Think of the pilot and crew the afternoon before a long-haul flight, none may have met, but all come together with one thing in mind: mission success.

Note: if a pilot or the crew feels compromised to endanger the mission's safe success, there is no penalty for declining the job (mandated by law in many countries).

In addition to this mental analogy of [pilots & crews] with [PM planners & teams], we should look at the physical tools the aviation industry deploys, but most PMs do not. The first one that comes to mind is a flight plan.

The flight plan.

All commercial aviation missions begin with a flight plan; consider starting your project with one. In this way, you are taking off from a cleared runway and not starting your project from mid-air, destined for trouble.

To a layperson, a flight plan may look like a form required by the FAA or other local authorities, but it's much more in a pilot's eyes. A flight plan for any pilot is a philosophy and a set of tools. The philosophy of the flight plan is to follow a set of actions that includes preflight, inflight, and landing checklists, as well as checklists for any emergency that modern aviation can envision.

The toolset behind a flight plan is extensive. Based on the aircraft flown (think project types), requirements, resources, and tailored checklists must be completed before any engine is switched on. These tools are modeled and taken from real-life experiences, simulators, manufacturers' specifications, and various other sources like the weather, weight on board, and fuel capacity.

The pilot and co-pilot complete and double-check the flight plan together, sometimes entering separate plans into a flight computer that double-checks the two human inputs and reports any conflicts. All of these calculations and checks lead to one question: Can mission success be safely achieved or not based on the destination? And remember, this is well before a single engine is fired up.

To complete the picture, here is a rough comparison between a flight plan and PM practices today:

Flight Plan vs. PM Plan
All variables are modeled and checked for compliance against specifications before starting.	Variables are considered ongoing risks and handled loosely.
Any change in plan is modeled in real-time (by a flight computer), and potential problems are immediately flagged with alerts sent to the pilot and co-pilot.	Changes may not be tested/modeled nor communicated to the PM or co-PM (or even with a flight control tower, or in PM terms, the PMO).
The flight continues along established waypoints, and cannot proceed unless all safety parameters are met.	Projects try to achieve arbitrary milestones and often proceed recklessly without meeting any.
Historical data is factored into the plan from the get-go.	Historical data on like projects is often unknown or not factored.
This type of plan is double-checked by a copilot with equal say in making changes and is also always communicated with flight controllers.	Plans often come down from "on high" and are developed without an independent double-check.

Inflight services...

Once in flight, or once Mission Project is safely off the ground, PMs have activities lumped into phases, sprints, and closings instead of a pilot's routine take-off, inflight, and landing procedures, yet these divisions serve the same purpose; to chunk the workload into manageable parts.

Yet more critical during these mission stages (even more than the lights displayed on the flight deck) is something called CRM, or Crew Resource Management, which often changes crew parameters and practices inflight, besides dictating normal behavior and communications. Every pilot or crew member has an HR department – inside their head!

One example of a CRM practice is the required sterile cockpit during takeoff and landings. This is when the pilot, co-pilot, and crew follow a strict protocol of keeping all chatter to a bare minimum, thus reducing the stress level during these critical moments and helping the crew execute the flight plan flawlessly. This is a feature developers of chat-based PM tools should take note of if they can.

Another example (also audible) is called a call-out within the Aviation industry. Ever wonder why pilots over radios repeat each change in the flight plan when communicating with air traffic controllers and even themselves? Because these call-outs have proven to save lives and planes from disaster! For example, you may have heard something like this in the movies when a tower is communicating with a jumbo jet: "Climb and maintain one two thousand" (climb up to and level off at 12,000 feet) with the pilot of the plane responding to the tower with the exact phrasing, "Roger that, climbing to one two thousand and maintaining."

This keeps planes from colliding on take-offs; in other words, there is confirmation and agreement between all parties on the line at the moment of decision. It is important to note that in the case of aviation call-outs, they are public so that other planes around the tower and ascending aircraft can also listen to the communication; but are respectful and keep it one way unless they have something urgent to contribute. Imagine your PMO is the control tower, you are the pilot, and your project is your mission - now you get the picture! Also, here's a shout-out to include call-outs in all PM software.

And while on the topic of tools and services, here is where the Aviation Industry flies far above what we have at our disposal as land-based PMs. They have a flight computer. And the flight computers on modern aircraft are remarkable, as they use the flight plan and constantly check progress against the plan, alerting pilots before anything goes off track. And as with any device, you can plug in new numbers and get updated results in milliseconds.

Yet here is where this metaphor becomes stretched. The variables involved in programming an Airbus or Boeing flight computer are finite compared to the number of variables in today's most complex projects. Yet, with that wide range of projects planned and executed over time, we could derive them, and predictive analysis is possible (with some margin of error). If only we had more of that, maybe our projects would not spin out of control as often as they do.

Note: Ever wonder why the airline industry has such an excellent record of success (as compared to our projects)? Then see this series of PM vs. Aviation articles.

Landing, not crashing

But even if you disagree that flying an Airbus is like landing a project on time, within budget, and with all goals achieved, you have to admit that the Airline industry has a much better record than ours, and with much less disastrous results in lost resources, wasted time and actual damage inflicted.

So perhaps even the thought of using a flight plan before project takeoff can’t hurt and possibly will prevent projects from becoming lost over some ocean, never to be heard from again. For those willing to try, here is a summary of thoughts for your next project flight plan:

Always make sure you start your project from the ground, and not mid-air, by stepping back 30,000 feet and examining exactly where you are – first!
Develop checklists based on past project performance and histories, and categorize and implement them by type of project.
Try to model a project’s results based on inputting historical/industrial-standard values for as many variables as possible – before taking off!
Use your plan to fly from one waypoint to another, ensuring all safety concerns are met before proceeding to the next.
Employ the latest model “flight computer” possible, to check your plan’s operating parameters in-flight and to alert you before problems arise.
Before taking off, always double-check your plan with a co-planner (call it a sanity check) and also share that planning with your PMO.
Even before assembling your team, consider the mental state of all involved. And during the mission, also be aware of cognitive problems such as bias, workload stress and other human-factor problems that arise within all hard-working teams.

Final (destination) thought…

So, in light of the above list of recommendations and other considerations within our theoretical Mission Project, here's wishing you the best in keeping the shiny side up whenever piloting a project to success.

For more info on the latest PM “flight computer” available, see the Project Plan 365 product page to learn how advanced planning software can improve your chances of safely landing your next project!

Is It Worth the Effort?

Posted on June 17, 2020October 25, 2022 by Captain

Is It Worth the Effort?

In Daniel Defoe’s novel of Robinson Crusoe and his adventures at sea, a notable quote stands out:

“[N]ow I [see], though too late, the folly of beginning a work before we count the cost, and before we judge rightly of our own strength to go through with it.”

Judging from the quote, there appears to be a point of no return in everything we do- our project endeavors included. As the S-Curve of “Cost” as it relates to “Time” ramps up the steep incline during project execution, we must ask ourselves: will it be worth the Effort?

Take an analogous jungle survival story:

Should a 300lbs lion burn 500 calories chasing a small rabbit that will give him only 100 calories in return? Of course, the answer is no. This reward is clearly not worth the Effort. Why is it then that you will never turn on Animal Planet and see such a lion act in this way, but you often hear of small businesses (90%) that fail in the first year and projects (80%) failing overall?

Common in the field of project management are the phases of project initiation and project planning which involve a Go/No Go decision template. It is one thing to make decisions before things begin to pick up, but what happens after we decide to Go and realize along the way it is not worth the Effort? Well, this when jungle-like survival skills must kick in.

Before anything else, you as a project manager must recognize and admit things are not going as planned. Then, you must act fast before is too late. If you find yourself in this position, begin by returning to your baseline assumption cost. What was it? You can easily name this “Day One Initial Estimate” and, you can usually assign a number (for example, $1 million).

Next, let’s consider your initial consideration of Total Estimated Effort for the work. What did you think the project would look like when finished based on the Effort? Here, my friends, is the tricky part... you didn’t consider this and that is why you are facing a problem. Had you known the Total Estimated Effort, you wouldn’t be reading this article and would be doing more enjoyable things with your time right now.

What I suggest at this point is you deal with Hope. Hope is your best friend and worst enemy. That is to say, you know there is a problem, but you Hope everything will be okay, right? Here, an additional lesson can be applied from Robinson Crusoe’s adventures- A lesson that I find to be magic put into practice:

“Today we love what tomorrow we hate.”

We tend to Hope for more happy days in our planning and wish that tomorrow too there will be a good day, but it doesn't always happen. Therefore, Hope should be a set for an exact period of time where you expect to see some specific positive results.

For example, if I take a pill for 5 days I Hope to see my fever decrease from 102 to 98 in about 5 days. Hope may prove positive or… maybe I die. Who knows?

Unlike a pill, we sometimes know there is barely any Hope, but we still try for that 1% chance. This is part of our innate decision making process that we cannot help but do (at least until AI takes over).

So, let’s define our Hope Period and Hope Target to try and determine if Hope assumptions will come true or prove to be false. You’ve got your project started, you are excited, everybody is on fire, budgets are approved, there are successful kick off meetings… now is exactly the time to be worried. Pay attention to the first 20% Effort period- it is the most critical part of your project. Add an extra 5% for the Hope Period where you can determine how much Hope you can hold onto; only then will you be in a good position to make some thorough Go/No Go decisions. And if you’re already deep into your project and all you have left is Hope, determine when Hope should be lost for the sake of your budget and team.

Don’t believe me about the importance of Hope? Google these big project failures that extended the Hope period just a little too far: The Canfranc Titanic of the Mountains project and The New South China Mall, Pearl River Delta.

Remember this: most of the project Effort understandings happen in the initial execution period, so pay close attention and the next time you begin to build your Microsoft Project, Primavera, Smartsheets, Project Plan 365 or any other project plan, add a Robinson Crusoe Milestones along the way and be prepared to answer his question:

Is it worth the Effort?

Happy Planning!

Putting Face-to-Face Meetings on Pause

Posted on March 23, 2020March 25, 2020 by Jigs Gaton

Putting Face-to-Face Meetings on Pause: A How-to for Project Managers

Tips for Running a Successful Remote Project Meeting

One of the biggest advantages of a face-to-face project meeting is that you and your team are collaborating in real-time, full-frontal, leaving little room for misunderstandings or misinterpretations. For example, in a traditional meeting, you and you team work to add, change, or delete tasks, assess risks, discuss dates, assign resources, etc. etc. Afterwards, everyone leaves the meeting with an updated and accurate plan. Easy.

However, during a remote project meeting (either by audio link, video link or both), certain challenges arise that you may not be comfortable with, or you might not have ever experienced. So here is quick head's up on how to get the most out of your next remote project meeting...

How to read body language, without a body...

When in person, and you ask a team player about a milestone or deadline, you can read the person's face to collect the "meta" information on the response. You know, that pained expression or the glint of joy in their eye; but when on the phone, you don't get any of that. As a PM, you now use your built-in sonar. Listen for silence. Either engage the silent one, or have a quick follow up after the meet is over.

When having a voice-only meeting, or a mixed video and phone meeting, make sure every attendee is engaged. One tip from native culture is the idea of passing a talking stick, where each attendee is given the stick, and a certain amount of time to "hold" the stick and talk uninterrupted. Try playing with an idea like this to ensure that everyone on the other end is alive, well and contributing.

The fashion trend of "Dress for Success" just changed...

Don't be surprised if your co-workers have shed Gucci for Nike, now that most of your team is working from home - you can even revel in the fact that your team is probally even more comfortable than ever! Being comfortable within a virtual meeting is absolutely important, but as your new role as moderator of a remote project meeting, realize that even in tees and shorts, that your team may be feeling anxious or uncomfortable within an online format.

When first starting a remote project meeting, allow time for everyone to just share what's going on in their lives, and to let loose about working from home. Again, make sure everyone gets a turn, and gently encourage those shy online to participate.

...Meeting strangers online is now ok...

Acting as a PM moderator, make sure everyone on the line (or on the feed) is properly introduced. You can prepare a few words on each person attending, and also allow each attendee a chance to introduce themselves. For folks new to the team, make sure there is a mechanism in place to share the "distribution" list to all, and that all know how to contact each attendee of the meeting.

Whiteboard it!

It's really surprising the amount of new tech involved with remote meeting apps and software! Interactive Whiteboards are great for brain-storming during your project meeting, and look for the feature that just captures the entire conversation - automatic meeting notes! In addition, tools like Project Plan 365, Microsoft Project or Microsoft Excel can be used in rTc mode (real-time collaboration) to update a project plan in real-time.

Do whatever you can to reduce any "new tech" anxiety or stress amongst your team. You may even have to have a training session first, on any new tools, before you start having official remote project meetings.

What to do when difficulties arise...

A myriad of difficulties can come up before, during and after a remote project meeting, but your most important action as moderator is to stay calm and carry on. Issues, technical or otherwise, can still be resolved on another call, either with a single team member or a smaller group. Be upfront with your team, as this may be all be new to all of you - honesty and patience goes a long way online.

Many obstacles can be mitigated ahead of time, using the tried and true approach of proper preparation. For remote meetings, this may mean a bit more time spent preparing for the meeting than you normally would (no longer can you dash from your desk to the meeting room carrying everything that you need).

Humor is highly encouraged... don't worry too much about "wasting" time, as a bit of light-hearted play might be just what a tense situation needs.

In conclusion...

Project meetings once held face-to-face, can now be just as successful when held remotely, but certain challenges will arise; for example:

Communicating remotely, where you may only be able to hear your team speaking, might take some adjustment. But have faith, back in the '50s this was the way everything was done.
As a PM conducting remote project meetings, you have, in a sense, become an online moderator. Any google resources on becoming better at that, is well worth your time.
Remote Meeting Technology is a blessing, but can be challenging to those new to the environment. Patience and prior training is key. Make sure you put those tasks in the plan!
Making team members comfortable and keeping the meeting relaxed is the perfect recipe for success.
Above all, keep calm and carry on!

To learn more...

Keeping Track with Agile

Posted on December 7, 2019May 6, 2022 by Jigs Gaton

Keeping Track with Agile... Using Project Plan 365!

Why Agile?

Agile project management is an iterative and incremental approach to delivering requirements throughout the project life cycle. Mainly used in software development, it has gained momentum in many other industries due to its emphasis on collaboration, flexibility, continuous improvement, and high-quality results. It uses popular project management frameworks such as Scrum (which uses Sprints that are time-boxed iterations, typically two weeks long and used to organize tasks and for quick goal shifting) and Kanban (which uses Backlog and Board status to manage work in progress).

Agile is great for teams who are looking for adaptiveness, clear and measurable deliverables, and a flexible approach to project delivery.

Why Project Plan 365?

Project Plan 365 supports both the Agile and Waterfall PM methodologies, all within the same app. That means you don’t have to choose one over the other - you get the best of all worlds - all in one place. With Project Plan 365, you can easily switch between Scrum and Kanban boards - with no disruption to data.

Project Plan 365 is especially data-flexible, meaning your data files can also be opened using Microsoft Project apps - as well as others - and Project Plan 365 actually extends the functionality of Agile planning over using Microsoft Project alone.

This tutorial will show you how to create your first Agile plan, and will also show you how to convert your Scrum to Kanban, in just one click. A practice file is available online, in case you want to follow along. If unfamiliar with Scrum & Kanban (and the difference between the two), see this cheat sheet from Development That Pays. Ok, let’s get started…

To start tracking your first Scrum...

1 Click on File/New, and choose Scrum Project.

2 The Sprint Planning Board displays, allowing you to add project tasks (as board items - just like sticky notes). Once added, you can move tasks into different Sprint cycles; just drag and drop to suit.

3 To create a new board item, click on New Task, and then fill in the task description, then click Add. Repeat for any sprint task you would like to create.

As you create the list of tasks, you sort them into Sprints (by default, three are included; Sprint 1, Sprint 2 and Sprint 3). In Agile methodology, a Sprint is a fixed time frame for work to be completed. By default, Project Plan 365 includes three sprints, with each sprint lasting 2 weeks (you can always add more; that's explained soon). As a result, the default Agile project duration is 6 weeks (3 sprints x 2 weeks):

Behind the scenes, as you add tasks to Sprint boards, they are also added to the Project Schedule. From these planning boards and sheets, you can always switch to any other view to see your data within different contexts. Go ahead, try it!

With the Manage Sprints sheet, you can set your Sprint durations (which can vary) and specify the start date of your first Sprint. All the other Sprints will be automatically calculated based on this first Sprint date. By default, Project Plan 365 generates Sprints through to the project’s finish date. But you can also specify a custom date:

At this point, the task dates are not updated within the Gantt Chart View to reflect the sprint dates – but we know the dates of each sprint by looking at the Manage Sprints sheet.

4 To move tasks between sprints, you can drag and drop them within the Sprint Planning Board:

And you can also sequence tasks using the Current Sprint Board:

5 You can complete task details for Sprint board items by using either the Current Sprint Sheet or the Sprint Planning Sheet; there you can add resources, deadlines, work estimates, as well as reassigning Sprint numbers or changing the board status for each task:

Both sheets are similar, with the major difference being that the Sprint Planning Sheet does not show completed tasks, and does show the Agile column by default.

You can add or hide columns to any view in Project Plan 365, for example you can hide the Task Summary column or add the Agile column anywhere you’d like. Also, setting Agile=No will remove that task from all Agile views.

6 You can further customize your sheets by, say, adding the % Complete column, and then tracking progress here:Both sheets are similar, with the major difference being that the Sprint Planning Sheet does not show completed tasks, and does show the Agile column by default.

7 You can also customize your boards by, say, adding/deleting/re-naming/moving board columns, or by deleting tasks, assigning resources, marking 100% completes, etc.

Switching between the two Agile flavors...

If you want to switch between the two flavors of Agile (Scrum or Kanban), you can do this from the Scrum ribbon/Agile, from the Project ribbon/Agile, or from the Kanban ribbon/Agile.

When switching to Kanban, you will see very similar features to Scrum. Kanban is all about visualizing your work, limiting work in progress, and maximizing efficiency (or flow). In contrast, Scrum has a Sprint Planning Board that allows you to select which tasks belong to each Sprint. You will not find this when switching to Kanban. Here you use the Backlog Board and Backlog Sheet instead (which is the similar to the Current Planning Board within Scrum).

In conclusion...

To sum up, in this tutorial we learned how to:

Start a Scrum from scratch.
Add tasks to the Sprint Planning Board.
Sequence tasks using the Current Sprint Board.
Add details to tasks and manipulate columns in both the Current Sprint Sheet and in the Sprint Planning Sheet.
Switch between Scrum and Kanban displays of the project plan.

For help with this - or anything else PM-related at all - please complete a support ticket and we’ll get right back to you.

To learn more...

Introducing Erix – Your Virtual PM Assistant

Posted on November 14, 2019June 17, 2020 by Jigs Gaton

Introducing Erix - Your New PM Assistant!

HELLO WORLD, and welcome to the 4th wave of the Industrial Revolution. This latest iteration of tech is marked by voice-activated AI, expanded robotics, IoT, autonomous vehicles and more... including software that solves tough problems - as well as performing menial or repetitive tasks best offloaded to a virtual assistant in the first place.

With that said, we would like to introduce you to Erix, the world's first Project Management (PM) Assistant built into your app. To introduce yourself to Erix, just open up Project Plan 365 and look to the upper-right corner.

Introducing Erix 1.0...

Erix 1.0 is currently an in-app chatbot that interacts with with you via the keyboard. You type in PM-related questions, such as:

What is a WBS?
What is Critical Path?
What is a Milestone?

Then Erix provides answers to these kinds of basic PM questions, and can also handle "How do I..." and "What is..." type queries.

In short, Erix 1.0 can help newer project managers with PM terms and methodolgies, without ever taking their eyes off the screen.

However, Erix is not stopping there...

Next Up, Erix 2.0...

The next iteration of Erix will do more, as this assistant becomes more intelligent over time and more familiar with the data sitting in your plans.

In Erix 2.0, you will be able to interact with your .MPP-formatted project files, and essentially help you improve your plans, just as any human team member can. For example, Erix will be able to answer questions about your plan-in-progress such as:

Show me the Critical Path.
When is the next Milestone due?
What tasks are running late?

Erix will give project managers a capable & smart assistant, without an added resource cost! In addition, any Microsoft Project user will be able to interact with Erix, by simply opening up the .MPP file in Project Plan 365.

Erix 3.0 and beyond...

Once Erix has graduated and is a certified PMP (from PMI), Erix will be able to:

Help you pass your own PMI certification exams.
Solicit real-world experiences from the PM the community (to help Erix better solve PM problems) using big data.
Support voice conversations between Siri and Google Assistant, allowing voice conversations between users of the app and Erix itself.

What You Can Do Now...

Are You Managing Risk? You Should Be.

Posted on July 20, 2019March 17, 2021 by Jigs Gaton

Are You Managing Risk? You Should Be.

Risk management is a fundamental part of any project management regimen, and if you are not following a process for managing any potential risks you may encounter along the way, you are in serious risk yourself; as risk not mitigated during the rollout of a project is a primary cause of project failure today.

But what is “risk” in the first place?

Simply put, risk is any uncertain event, task or condition that impacts at least one of the project’s objectives as it occurs.

Fortunately for planners, there is a well-documented protocol for incorporating risk taking (and risk management) into your daily project-management routine. This article covers a basic risk management protocol, provides templates to follow that protocol, and then describes how you can use Project Plan 365 to help you mitigate risks along the way. While Risk Management is a well-documented discipline in itself, by following a simple procedure and creating a document or two, anyone can successfully prepare for and mitigate risks as they present themselves…

Risk Management Basics

First, the process of risk management for any project goes like this:

Plan for any potential risks you may encounter during the life of your project (create a Risk Management plan, specific to the project on hand). A downloadable template is provided here to get you started.
Layout a process for risk identification, analysis, response, monitoring and reporting within the newly created plan. In addition, any contingency plans for the identified risks should be documented here, along with those responsible for carrying out the prepared mitigations (command & control).
Develop a risk register to identify risks, where you rate the likelihood that the risky situation will occur, the seriousness of each risky situation, and the impact on the project if that risk were to go unchecked. A downloadable template is provided here to help you out.
Maintain a risk log, documenting any interventions and follow-ups as needed.
In your planning software, identify risky tasks and review them periodically as your project is rolled out. Also, update your project plan based on any risk mitigations performed, or new risks encountered.

Now, for those using Project Plan 365, the following tutorial will get you started recording and displaying risk within your plan.

Note to Microsoft Project Users:
If you are a Microsoft Project user, you can use this procedure as well, but you must first use Project Plan 365 to set things up within your .MPP file. Then, when you open up your project file in MS Project, you should see any identified risk as described below (just add a column containing Outline Code7 and rename the column to Risk).

Identifying Risky Tasks within Project Plan 365

Project Plan 365 offers a simple yet effective way of tracking and managing the risks you have identified in your Risk Register (from your Risk Management Plan). Just follow these steps to get started:

1 ) To turn on the Risk Management feature within Project Plan 365; just go to Backstage | Options | Risk Management and click the Enable Risk Management System checkbox, and then tap OK.

2 ) Once the Risk Management System is enabled, switch your plan to the Risk View, where you can identify any risky tasks in your plan by changing values in stored in the Risk column: *

The Risk View is handy, as this view allows you to go through your entire plan to quickly “tag” tasks with a risk value, and then this view will automatically sort all tasks by the value selected (in this case: low, medium, high or No Value).

3 ) You can also add your Risk column to any view you desire, for example, to the Gantt Chart View:

4 ) Using the Risk column (by clicking the twisty), you can filter out the values you don’t want to see. In this example, we are filtering on just the high values. Once filtered, the view will only show tasks with a high-risk value:

In addition to filtering risky tasks to display just what you want, you can also customize the default risk labels to display anything you want, such as labels used in your Risk Management Register, Logs, or Plan. Just edit the Risk Level grid found under Options to suit your requirements:

Risk Reporting Within Project Plan 365

Once Risk values are added to tasks, a Risk Report can be generated by navigating to the Report ribbon and selecting one of the available reports:

Summing Up...

By synchronizing a Risk Management Plan right alongside your project plan, you can track risky tasks within your schedule, and stay on top of any activity that may go wrong during the course of your project rollout. In addition, you can produce Risk Reports or otherwise use your project schedule to control and mitigate risks as they materialize, all according to plan.

To start managing project risk today, subscribe to the Project Plan 365 Business Plan without delay!

Risk Management the easy way - subscribe to Project Plan 365 today!

For more information about Risk Management within Project Plan 365, see this help page.

Simple Calendaring in Project Plan 356

Posted on March 31, 2019April 6, 2020 by Jigs Gaton

Simple Calendaring in Project Plan 356

When scheduling a project in either Microsoft Project or Project Plan 365, you can change the calendar for your project, i.e. the days your work is ongoing – or not! In fact, you can tailor calendars in many ways, for example, you can have unique calendars for people (resources), for tasks and for the project as a whole. Having all these custom calendaring options is great, but can be a bit complex and confusing to set up (see here).

What if all you need to do is change the days of the week everyone is working, for example if your project locale is somewhere Friday & Saturday is considered weekend time off (or, if you are lucky enough to just work 4 days a week instead of 5)? In these simple cases, the latest version of Project Plan 365 provides a much easier way to change your project calendar.

And what if you just want to extend the default work week (M-F) by one day, perhaps to finish up some work left over from Friday, using Saturday to get that done. Here too, Project Plan 365 provides a quick way to change the project calendar to reflect that one extra day of work.

Case 1 – Changing the Default Work Week

In the case where all want to do is adjust the work days within a week, for example, to indicate your project is being rolled out Sunday through Thursday, instead of the usual Monday through Friday, then just follow these steps:

1 ) Open Project Plan 365 and go to the File menu to select Options:

2 ) In the Options dialog, go to the Schedule tab and check or uncheck the desired-working days from the Default working days group:

In the example above, we’ve changed the default work week, and have also updated the default project calendar all in one go.

3 ) Click OK.

Case 2 – Changing a Single Day

In the case where all want to do is extend or limit your work by a single specific day, for example to finish up some work left over from Friday - on Saturday, then just follow these simple steps:

1 ) Within your plan, open the date-picker from anywhere within in the Start/Finish column and click on any non-working day that you wish to change (in this case, Sat):

2 ) When clicking a non-working day (or a working day for that matter), an Alert message appears, from which you have these three options:

If you selected a non-working day (in this example, Saturday the 7th) and then hit the Make this a working day radio button, clicking OK makes that Saturday a working day.

3 ) Here you can also Adjust the default working days (just as we did in Case 1 above), i.e. if you decide you are working all Saturdays from here on out, you can just select the Saturday checkbox to make that so:

4 ) Click OK, and you’re done.

Summing Up...

For these common cases of calendaring adjustments, you can simply use Options / Schedule to change the default work week, or just click on a Start/Finish date (from any view) to make changes to a particular day. This technique greatly simplifies tailoring your work days to the days you are actually working - or not!

Note: Of course, you can always do all of this the “hard” way (by using the Change Working Time dialog), but the two cases described here do not need such heavy lifting, and this simple method allows Project Plan 365 users to make the most common calendar adjustments in the shortest amount of time. (Sorry Microsoft Project users, this feature is not available to you.)

To start calendaring the easy way, subscribe to Project Plan 365 right away!

Taking Snapshots, the Project Management Way

Posted on March 22, 2019March 31, 2019 by Jigs Gaton

What is a Baseline?

A baseline is generically known as a value or condition against which future measurements can be compared. Within the context of project management, these values and conditions are the project’s scope, cost and schedule. A project baseline can be thought of as a “snapshot” of a project’s initial condition, just before work begins.

Baselines are used to evaluate project performance over time, by comparing an initial project snapshot with any subsequent images captured while your project progresses. Baselines are also used to quantify any variances from the original plan while the plan is in motion.

You can also think of a project baseline as a “sanity check,” in the sense that project sanity is defined as not making the same mistake over and over again while hoping for a better result!

Once your project is designed, capturing an initial project baseline is the first step taken to ensure better project performance — and PM sanity – over time. The baseline draws a line in the sand that says, “This is what we thought was going to happen, vs. what actually happened.”

Most decent project management tools have a feature for capturing the initial baseline and displaying any variances from that initial line in the sand. Project Plan 365 & Microsoft Project are no exception. Both can store and display up to 10 baselines for any given project (or for a select group of tasks). The typical baseline metrics most project managers use are: baseline duration, work and cost. However, many other metrics can be defined and then displayed.

When setting up a project plan, it is important to remember to set the initial baseline before putting the schedule into play. In other words, this step needs to be taken before work begins, but after you have designed your project plan and when you are ready to roll.

Note: Forgetting to set an initial baseline is a common mistake, and this boo-boo can’t easily be rectified once your plan is in motion.

>>> To work along with the following tutorial, download this sample plan (and Project Plan 365, if you don't have already) <<<

To visualize how a baseline is used, let’s take this simple three-day, three-task, three-person project as an example, before the initial baseline has been set:

Step 1. Open a plan in Gantt Chart view for a project with no baseline set:

Step 2. Navigate to the Project ribbon / Set Baseline and set the baseline there:

Once you have set an initial baseline, the app begins crunching numbers and updating baseline values in fields and on the Tracking Gantt chart, as each change is made:

Step 3. Now with a baseline set, you can begin tracking and then see the changes made to your plan. Let’s assume that our three-day, three-task, three-person project was completed, but with Team member 1 — being the slowpoke that he is — is taking two days to complete the one-day task as planned. The resulting display in our project plan now shows this variance, using actual values and baseline values - and displaying a baseline “shift” in the Tracking Gantt chart:

Variances (baseline shift) are shown in baseline fields and on the Tracking Gantt chart. Baseline shifts are an important indicator of project performance over time and should be employed by every project manager when evaluating project metrics.

A quick way of seeing these shifts in your plan, is to use the Project ribbon to view Project Information / Project Statistics, which are updated in real-time. Project Statistics shows basic baseline values and variances from the actuals:

-- This article first appeared on MPUG.org on November 21, 2017 and appears here with permission of the author.

To begin implementing baselines within your plans, simply subscribe to Project Plan 365 today!

Innovations in Sub Building – and PM!

Posted on March 22, 2019March 22, 2019 by Jigs Gaton

How New Technology, Better Collaboration, Simulations and Modular Designs Make for Project Success: An Examination of Nuclear Submarine Building

Some of the largest and most expensive projects completed of late have been fraught with huge time & cost overruns. These unexpected delays and expenses cause partial or full project failures with much hardship for all involved! Yet there have been a few cases where multi-billion dollar projects have been completed on time, under budget and beyond all odds - with a minimum of rework. Well, reasonably so…

The development of the USA’s Virginia-class nuclear submarine – a collaboration between two fierce competitors (General Dynamics and Newport News Shipbuilding) – is just such a success story. This US DOD project produced modernized submarines that cost far less to build and maintain than the previous model then in service (the Seawolf-class submarine). There were four key innovations that contributed to the Virginia-class project success:

1. Virginia-class submarines were designed using the then new technology – CAD (computer-aided design) – eliminating the mountain of paper blueprints needed to begin the project.

2. Resources from two competing companies were employed in order to cut down on build time – placing them in anunnatural collaboration.

3. A simulator was built to test the design of crucial command components – before installation on the submarine assembly.

4. The interior of the submarine was built in modular parts (some the size of a small house) that could be slid in and out of the hull later on down the road, thus extending overall life expectancy of the class.

By examining these innovations more closely, we can glean our own lessons-learned likely applicable to our own projects, no matter how large or small.

How innovations in technology helps any project manager…

It may seem obvious to use the latest & greatest technology when starting a new project, but that is not always the case. Sometimes project managers like to stick with what they know (works), and also like to play it safe, “If it ain’t broke, don’t fix it.”

This wasn’t the case for Virginia-class planners, as they knew they needed to use technology innovations to bring their project in under budget, and under the intense political scrutiny of 1990’s defense-budget reviews. So they took a gamble, used the new CAD software and went completely paperless for their build plans.

Now while today’s planning tools have made great strides in the elimination of all sorts of paper previously employed (by just using our beloved software), we should also follow the Navy’s lead and hold technology reviews. Since new tech arrives almost daily, we should examine new developments in technology before the start of every new project.

For example, if one were starting a project today and haven’t upgraded to Project Plan 365 (Business or Enterprise plan) - or Microsoft Project 2019 - then some thought should be given to upgrading. But no matter what technology you are using to plan and rollout your projects, it’s important to know that the tech is changing all the time.

How innovations in collaboration can turbo-charge project finish-times…

As project managers, we are always talking about collaboration (one of the most famous buzzwords of the 21st century), but from what I’ve seen, we rarely innovate in this regard before the start of each new project. We suggest a “collaboration review” before the start of your next project, where your team spends some time discussing how to better work together on the next new thing – take the Navy’s lead here and consider something outrageous and uncomfortable, like collaborating with the competition. That’s what the US Navy did when rolling out the Virginia-class project, and they shaved years off delivery times.

Another good idea is to take a look at Real-Time Collaboration (rTc), which is a feature of Project Plan 365 that puts all the players together - from design to final wrap-up.

How innovative modular designs can save you time and money…

We tend to think of modularization as something that happens during manufacturing processes, like building “plug & play parts” for phones or cars. But have you ever thought of building project plans in a modular fashion? Fortunately for Project Plan 365 and Microsoft Project users, this is such an easy thing to do – if some foresight is used.

Project Plan 365 users that have subscribed to either the Business (PMO) or Enterprise (EPM) plans, can build parts of a plan, manipulating either individual parts or the whole plan at will. Likewise, Microsoft Project users can use the Master Project / Subproject feature to build modular parts of a plan, and those parts can be easily re-used later on down the line.

Hint: Subprojects are the reusable bits. That’s what the Navy did with reusable parts of the submarine, so surely we can do that with our projects. The end result will be less time spent reworking old plans to fit new projects, and in short, we’ll just save a lot of time and money.

How innovative simulations can make any project more risk-resistant…

The Virginia-class engineers knew they had no time to design components that would later have to be redesigned because they didn’t quite work when actually installed in the final product. So they built a simulator to test critical component-designs before actually putting them into action. (As an added benefit, personnel who would later have to operate those components, had a shorter learning curve.)

Use Project Plan 365 / Microsoft Project to do the same – by conducting what-if scenarios during any initial project plan design. It’s so easy to do: just run simulations by changing draft plan values inside of the app – thus simulating various scenarios, like unexpected changes in resource allocations, schedules or budget.

Similar to what Navy engineers did with their simulator, project managers can make their project plans more efficient and less risky by first spending some time running project-plan simulations – before ever putting the plan into play!

So you’re not planning on building a nuclear submarine anytime soon…

Of course, most of us are not planning on building a replacement for the Virginia-class submarine, or any kind of billion-dollar submersible for that matter, but by taking the lessons learned from those that did, we can see how the innovations deployed on that project can lead to our own – even if our projects are much smaller and less costly.

By innovating our use of technology, new collaboration techniques, modular plan designs and simulations, we too can roll out projects as successful as the Virginia-class nuclear submarine.

-- This article first appeared on MPUG.org on November 21, 2017 and appears here with permission of the author.

To begin leveraging innovation in tech, collaboration, modularization and simulaton, simply subscribe to Project Plan 365 today!

What is a Work Breakdown Structure?

Posted on March 21, 2019March 21, 2019 by Jigs Gaton

What is a Work Breakdown Structure (WBS)?

A work breakdown structure or WBS is a common term in project management. The concept is used each time a new project is designed — and is best thought out before entering any data into a .MPP file. Yet even though the WBS is an important construct to project managers, creating and using a WBS in the project design phase does not occur with the regularity that you might expect.

Some of this lack of use of the WBS stems from the complicated definition; a 243-page specification published by the United States Department of Defense (MIL-STD-881C) was initially developed back in the 1960s to help NASA and the U.S. military better manage mega-projects, like building rocket systems or getting to the moon. Yet for those outside of the US government, no one wants to adopt a practice that takes 243 pages to describe.

It doesn’t have to be that difficult.

A WBS is really just a visual breakdown of a project into smaller components — think hierarchy – which makes planning for (and creating) the required deliverables easier to accomplish for any project team.

The benefits of designing a project that incorporates a WBS are multifold:

The WBS helps define key deliverables and sub-components of deliverables before work is scheduled and started, resulting in a smoother rollout during the project. The scope of your project is captured in the WBS, helping to prevent mission- or scope-creep later.
The WBS provides a much-needed collaborative tool that can be reviewed early on with project teams, management and other stakeholders before a plan is locked in.
The WBS gives everyone a clear, visual representation of a project, without having to wade through the minutia and tedium of other types of project metrics or documentation.
Through use of a numbering schema, the WBS identifies parts of a plan numerically (often called WBS codes), which can be used in many ways during the execution of your project. For example, a repetitive deliverable that is identified by number can be easily resourced, costed or scheduled programmatically from within Project Plan 365 (or many other scheduling tools).

To develop a WBS for your next project, just follow these three golden rules:

First, the 100% Exhaustive & Mutually Exclusive Rule provides that within every level of your WBS, everything you need to deliver is represented within that level. For Level 1 of your hierarchy, for instance, you should find everything that you need to deliver for your project in totality. Within level 2 of that hierarchy, everything you need to deliver for that subcomponent of your project is included (and nothing else). There should be no overlap in scope between the various levels of your WBS. Just the act of creating the WBS exposes deliverables or events that may detrimentally overlap in your plan — and therein lies the beauty of employing a WBS. This figure shows a sample WBS structure set up in a “mind map” format.

Second, the Make a Logical Structure Rule provides that you make a visible representation of your WBS in a hierarchy that makes sense, and is easy to read. In olden times, this was often done in PERT charts. In today’s world of simplification, a much more recognized and modern visualization tool is the ubiquitous mind map, as shown in the figure above.

Note: the numbering schema that goes along with this hierarchy can be automatically generated within Project Plan 365 (see Figure 2 for an example), and WBS codes should be generated this way instead of typing them within the Task Name.

Third, Grammar Rules should be followed, but don’t worry, this grammar is easier than you think! Here’s how you do it:

Use descriptive nouns to describe all your deliverables and sub-deliverables
At the lowest levels, use action verbs to describe what’s needed to make each sub-deliverable “happen.” Figure 3 shows WBS grammar rules in action.
Use row #1 to name the project and set the title of the plan.

In summary...

By following these three golden rules, your WBS will become an invaluable tool throughout your project planning experience: from the initial design collaboration – to the actual scheduling in Project Plan 365 — you will surely come to depend on having a WBS prepared for every project that you manage.

Avoid Project Crashes:

File a Flight Plan First!

By Jigs Gaton, PM / Pilot

First, let's step back 30,000 feet

Where does Mission Project begin?

The flight plan.

Inflight services...

Landing, not crashing

Final (destination) thought…

Is It Worth the Effort?

Putting Face-to-Face Meetings on Pause: A How-to for Project Managers

Tips for Running a Successful Remote Project Meeting

In conclusion...

To learn more...

Keeping Track with Agile... Using Project Plan 365!

Why Agile?

Why Project Plan 365?

To start tracking your first Scrum...

Switching between the two Agile flavors...

In conclusion...

To learn more...

Introducing Erix - Your New PM Assistant!

Introducing Erix 1.0...

Next Up, Erix 2.0...

Erix 3.0 and beyond...

What You Can Do Now...

Are You Managing Risk? You Should Be.

Risk Management Basics

Identifying Risky Tasks within Project Plan 365

Risk Reporting Within Project Plan 365

Summing Up...

Simple Calendaring in Project Plan 356

Case 1 – Changing the Default Work Week

Case 2 – Changing a Single Day

Summing Up...

What is a Baseline?

>>> To work along with the following tutorial, download this sample plan (and Project Plan 365, if you don't have already) <<<

To begin implementing baselines within your plans, simply subscribe to Project Plan 365 today!

How New Technology, Better Collaboration, Simulations and Modular Designs Make for Project Success: An Examination of Nuclear Submarine Building

How innovations in technology helps any project manager…

How innovations in collaboration can turbo-charge project finish-times…

How innovative modular designs can save you time and money…

How innovative simulations can make any project more risk-resistant…

So you’re not planning on building a nuclear submarine anytime soon…

To begin leveraging innovation in tech, collaboration, modularization and simulaton, simply subscribe to Project Plan 365 today!

What is a Work Breakdown Structure (WBS)?

In summary...

To give Work Breakdown Structures a try, simply subscribe to Project Plan 365 today!