Using Microsoft Project Plan to Create an Updatable Project Plan

While most of the Project Managers are well versed with the Project Planning process, many end up being not so efficient at tracking of the Project Plan. In this article I aim to provide a quick guide for the budding Project Managers to be able to make use of the "Auto-Scheduling" and "Baselining" features of Microsoft Project Plan (MPP) to create and track to a plan in an efficient manner.

For the purpose of this article, I will be using MPP 2013. However, the concept will apply equally well to MPP 2010.

Creating an Updatable Plan:
Here I will explain a method that I have followed for years to create plans that are easily updatable at a later stage without too much of manual work. The key here is to avoid constraints that will add in the way of auto-update at a later stage.

Step 1 - Switch on the "Auto Schedule" feature of MPP as shown in the below screenshots

Step 2 - Add a Column for "Work" to the MPP file and call it "Effort"

Step 3 - Set the Project Start Date in the Project Tab -> Project Information -> Start Date field

Step 4 - Add all the tasks along with their subtask hierarchy to the "Task Name" column. This will create the tasks corresponding to each entry as shown below.

Step 5 - Add Effort in hours against each of the leaf tasks under the "Effort" column as shown below. The Efforts under the non-leaf tasks will get calculated automatically.

Step 6 - Add sequencing of the tasks by entering the "Predecessors" column values as shown below.

Step 7 - Enter the Resources who will work on each of the tasks under the "Resource Names" column. At this point, the efforts may change to compensate for extra resource allocation. Change the effort to original one if needed. This will make the resource utilization change. Add all the resources without worrying about the utilization.

Step 8 - Adjust the duration to make resource utilization equal 100%. As you change the duration, effort will change to compensate for it. However, a context menu will provide an option to alternatively change resource allocation (as shown below). Select the option to change resource allocation to 100% and retain the original effort.

At this point the plan is ready with no constraints to it. The trick here was to never have to set the Start and Finish dates manually. Since those dates are auto-scheduled, and subsequent changes in the plan will just readjust those dates, without the project manager needing to revisit and rearrange all the tasks.


Adding a Delay to a task
Let us say that Subtask 3 in the above plan gets delayed by 1 day. In that case, the plan can be readjusted simply by changing the duration of Subtask 3 as shown below.

Delaying the Start of a Task
If, for example, Subtask 3 needs to start 2 days later than the original plan, a delay can be added by adding a leading buffer in the predecessor column as shown below.

Note that in all these cases, the plan remains self-adjusting so that the Project Manager can try out various scenarios to choose the best possible plan.

As always, please feel free to provide your comments and questions. 

Scenario based Agile

Scenario based Application of Agile Methodology to Project Management

Being a Project Manager for past several years I have often found myself and other Project Managers struggling with the problem of when to use Agile. In this article I try to specify a few scenarios which may lend themselves to effective Agile Project Management, and in the process I hope to answer some of the questions that have bogged the minds of my peers.

However, before we delve into the various scenarios, it would be of consequence to do a quick review of what makes Agile Methodology so unique and unorthodox. Below are a few of my understandings around this:

1. Agile works best with a team with a Flat hierarchy
2. The success of an Agile Project is measured by the Business Utility of the product (quality-centric), rather than adherence to the plan (variance-centric)
3. Concentration leans towards Product Design more than it does to Risk Management. In other words, risks are acceptable as long as the reward is substantial enough
4. Teams are self adjusting and self organizing 

These factors make Agile a preferable methodology for some scenarios at the same time as it makes Agile disastrous for some other scenarios.

Scenario 1 - Chaos
"The Software Developer is a Startup with a great idea whose incubation period is about 1 year"

Primary Considerations for Choice:

• Startups tend to be less structured and therefore a flat hierarchy will be more achievable and acceptable.
• Startups typically employ top-notch resources and therefore the team members will most probably be self-motivated and genuinely knowledgeable.
• Since the idea is at its inception stage, there may be various changes identified and required during the course of implementation. This would make the Agile's ability to adjust and re-adjust to change (essentially being "Agile"), of paramount importance
• Since the Startup is developing the software themselves, there should be no reason to identify a fixed-price/scope based implementation approach (which is where Agile miserably fails).

Therefore, in this scenario, Agile is not only a preferred implementation methodology, but also an essential choice for success.

Scenario 2 - Dictatorship

"The Software Developer is a Services company who is developing an E-Learning platform for its client. The client is insisting on signing a Fixed Price contract for this engagement"

Primary Considerations for Choice:

• No Advantage - Since the requirement is pretty standard, there is not a lot of requirement for innovation on-the-fly. Therefore the requirement will remain more or less static and the major advantage of change management, gained from Agile will be minimized.
• Disadvantage - In a Fixed Cost scenario, using Agile may mean Risk Amplification, as the cost will not vary in case the project needs to be extended due to the minimalist planning warranted by Agile. 

Therefore, the use of Agile in this scenario is not only fruitless, but may also end up being harmful to the overall endeavor.



Scenario 3 - Democracy
"The Software Developer is a Services company who is developing a new Eatery Location/Suggestion system based on implicit preference analysis of Usage patterns. The client is insisting on signing a Fixed Price contract for this engagement"

Primary Considerations for Choice:

• This is a balanced scenario where the requirements are not well established but the cost of implementation has to be fixed.
• Agile would be preferred in this case as the requirements are volatile and may evolve as the implementation proceeds.
• Additionally, the client may want to have a view of the production progress, sooner than later, as the concept is R&D based and prone to misinterpretations by the team.
• The constraint of a fixed price can be achieved by breaking down the work into calculable units and then exchanging the units to ensure that the overall value of the scope remains the same, even if the scope itself changes.  

The use of Agile in this case is the lesser of the two evils. Since the client is looking for a Fixed Price against a variable scope, the situation is tricky and slightly impractical to begin with. However, the Waterfall model in this case holds a much greater risk due to the delayed visibility and feedback.

I hope that the above should help put things in perspective for the reader and help them make an informed choice of project management methodology, specifically Agile.

As always, your comments and suggestions are welcome.

The Agile "Mindset"

Most of the Project Management Community in Software Development has been trying to imbibe and use Agile Methodologies in their production processes, but very few have been successful in delivering to the promised potential. In this article I will try to bring to light some of the obvious but less known concepts that prevent us from realizing the full potential of the Agile Methodology.

Agile as a "Mindset" - For most of us, Agile is a set of processes and practices - Scrum, XP etc. - that define the way to implement an Agile methodology. However, few realize that the true meaning of Agile is to be just that - AGILE. If this was Just Another Set of Processes (JASP), there would be little point in calling it Agile. Its Agile because it is supposed to be a flexible and tailor-able to the needs of the organization, without being restrictive in its implementation. Quite simply put, Agile means doing things the way it works Best.

But isn't that Anarchic and Chaotic??

Well, that is partially the point. In order to understand this, let us try and understand the basic difference between the way things work in Agile Vs Non-Agile worlds. As an example, let us compare the Software Development Process to the Car Assembly Line.

Car Assembly	Software Development
Outcome is knowable	Outcome is not tangible
Change is Expensive	Low Cost of Change
Boundary of Completion is Well Defined	Work will expand to take up the amount of time available, based on the desired quality

Therefore, in Car Assembly Line we need “Trained Workers” whereas in Software Development we need “Knowledge Workers”. However, most of the times we try to apply the Assembly Line processes to Software Development. Therefore, while implementing Agile, all we want to do is DO Agile. Instead, the full potential of Agile can only be realized by Being Agile.

What does it mean to BE Agile?

Agile is not a set of procedures but a mindset. And in order to switch to this mindset, one needs to inculcate the following:

• Welcome Change
•  Failing Early
• Build and Feedback Rules
• Continuous Delivery
• Value-Driven Development
• Small Value-Add Slices
• Learn Through Discovery
• Continuous Improvement

These few points move the style of working from the Assembly Line mindset to the Knowledge Worker mindset. As a Knowledge worker, you are not Trained but Educated. Instead of following processes, you learn to Create processes that best fit your needs and provide the best results.

Therefore, Agile is not chaotic, anarchic or process deficient. It is a way of working where the process is applied if it works and only the processes that work are applied.

Scrum, XP, Product Backlog, Continuous Integration etc. etc. are just practices and tools that have been designed to give you a head-start into the Agile way of work. But at the end of the day the point of being Agile is that you may formulate your own unique tool/practice that works best for you.

Note that in order to be truly Agile you will need to get out of the mindset of “Just tell me what to do” to the mindset of “I have a problem to solve”. And that is when you move from the Assembly Line way of thinking to the Knowledge Worker way of thinking.

I would like to end this article with an illustration that conveys the difference in the mindsets very beautifully.

(This article has been largely inspired by the very informative Webinar done by Ahmed Sidky on September 25, 2013. The recorded video of the Webinar is available here. I would highly recommend anyone reading this to view this brilliant presentation)