5 Tips for Making Microsoft Project Pretty

Most people who are not Project Managers do not like looking at Microsoft Project. In fact, their feelings are often much stronger than that. The common thread I hear is that it’s just too hard to understand. And indeed it can be.

Part of the reason is that Microsoft is very responsive to customer input, so they tend to adopt many of the suggestions users make, adding to the power and complexity of the software.

Microsoft Project is an extremely powerful piece of software that can hold scores of pieces of data for any given task. Most of those data mean nothing to the resource who just wants to know what she should be working on next.

If you do these five things, you will make Project easier to read, break down resistance and increase adoption of the tool:

1. Simplify. Consider your audience and the purpose. What do they need to know? What you need to present for a planning meeting is quite different from a status meeting. Once you’ve decided what is needed, hide columns that are not relative to the meeting. Create and save these views for easy access so that you don’t need to recreate them every time.

2. Size. Rows and rows of information seem to run together to people unfamiliar with Project. Be kind to your audience. Use double height rows and boost your font a little bit. On the Gantt side, increase the bar height  in layout from the default 12 to 14 or even 18.

3. Filter. If you’re showing 1,000 lines in a project plan to a limited audience that needs to see 20 lines, you’re going to lose them. Filter by date, resource or some other relative criteria to narrow down your presentation.

4. Color. Black text against a black grid is very difficult to read. Choose a font color that stands out from the grid like a blue or maroon. Call attention to key tasks by using different font colors or highlighting rows with background color.

5. Explain. Help people understand what they are looking at so they become more comfortable with the content. What is familiar to you may be foreign and incomprehensible to your audience. If you have taken the first four steps, you will have an easier time with this.

Microsoft Project Task Type: Fixed Units

Microsoft Project uses Fixed Units as the default Task Type when a new project is started. This results in behavior that is useful for basic scheduling, but can be a problem if the plan is being used for estimating hours and costs. Recall the equation Work = Units X Duration. If a task is entered first entered as a three-day task with one resource in the Fixed Units mode, the work will be calculated as 24 hours, assuming an eight-hour day. This means the resource is assumed to be dedicated full-time to the task for the three day duration, often not the case.  If later in the planning process, we discover that it is going to take 10 days to finish the task, and only the duration is changed, the equation does its job and the work is now 80 hours. Is this a true reflection of the work?

It may be.  But the question that must be asked is; is will the amount of work (24 hours) remain the same when the duration changes? This is often the case in a matrixed environment where resources are not dedicated to the project. If the actual effort is 24 hours, then you must change the Task Type to Fixed Work before changing the duration of the task.

In Project, do this exercise.

1. Add a new task and simply name it Task 1. Be certain that you are in Auto Schedule mode.
2. Add a resource named Resource 1 and make the duration three days.
3. Open the Resource Usage view and look at the work for Resource 1 for Task 1. It should be 8 hours per day.
4. Go back to the Gantt Chart and open the Task Information dialog box by double clicking on the task.
5. In the Advanced tab, change the Task Type to Fixed Work and in the duration to 10 days.
6. Return to the Resource Usage view and notice that the resource is now working 2.4 hours per day on Task 1.

In future posts, we will look at the other Task Types and the concept of Effort Driven. Feel free to contact me if you have questions.

 

 

 

Five Essentials for a Solid Project Schedule

If you are using Microsoft Project as your scheduling software, there are several things you can do to ensure that the plan is an effective tool for describing and controlling the project work.  Naturally, there are many other ingredients that go into a successful project schedule, but start with these and you will have a solid foundation.

 

1. Name Tasks for Action. Your tasks must be descriptive of the work to be done and be able to be understood in isolation from the rest of the schedule.  Remember that your resource may see the task without reference to the summary task, so in a multiple release software a task that says Test has no meaning. This is also true when you filter the schedule.  Test Billing Interface tells the reader what he or she is testing without needing to refer to other areas in the plan.
2. Use automatic scheduling. The reason you are using MS Project is to tell you, based on your resources and work estimates, when your project will finish, and it informs you of issues so you can make course corrections when things don’t go according to plan. If you are in manual mode you might as well use Excel as you will not have this functionality.
3. Make sure everything has a predecessor and successor. Without dependencies between all tasks, you cannot determine a Critical Path. Consider using Start and Complete milestones to tie loose tasks to where dependencies are not apparent.
4. Understand the impact of Task Types. This is perhaps the most misunderstood and yet most important parts of MS Project.  More people get frustrated by this than anything else and end up reverting to Manual Scheduling. There are three Task Types in MS Project: Fixed Duration, Fixed Units and Fixed Work. Choosing one locks that variable in the equation, Work = Units x Duration. Once you select a Task Type, changing any of the variables affects the rest of the equation, which is why seemingly crazy things can happen when hours, duration or resources are added to a task. Also, be aware of the Effort Driven choice. Can two resources accomplish the work in half the time?
5. Learn How to Print the Gantt Chart. I’m sure you’ve seen this. A schedule is printed with one page of the table showing the task names and 28 pages of Gantt bars. Even though paper delivery is not used often today, this is still important when printing to a PDF file for sharing with non-project users. Setting up the page is tricky and requires adjusting the calendar and zoom to get things just right. Also, eliminate any columns that are not required to tell your story, especially the Information column which has no use in printed form.

These five steps are essential to the mechanics of creating a meaningful project schedule. Combined these with your experience in estimating work, assigning resources and updating progress and you are on your way to success.

Using a Hybrid Methodology for Software Development

Despite the promise and growing adoption of agile methodologies for Project Management, Waterfall, or some form of it, will be around for some time to come. The reasons are rooted in the way organizations work, an importantly, how they make decisions on how to spend money on projects. Having a defined set of requirements up front, even knowing that they will change, makes it easier to decide whether or not a project is worth pursuing. But why not take some of the techniques of agile apply them in a Waterfall project?

Requirements are a good place to start. Why not use the scrum method of User Stories as a starting point for Functional Requirements? Recall that the format of a User Story is As a <type of user>, I want <some goal> so that <some reason>. Using this as a baseline creates a foundation to build upon for greater detail, create Technical Requirements and even write test scripts.

Another technique that is very effective in any project is the daily standup meeting. Too often in traditional weekly project meetings, issues are exposed that then take another week to resolve, and then slide another week after that! And many times these are issues that take hours, not days, to resolve. Quick, daily meetings designed the same as in SCRUM can avoid this and shave off valuable time from projects.

And rapid prototyping can greatly improve the acceptance rate of project deliverables. From a user standpoint, it is very difficult to imagine what something will look like in a new product and how it will satisfy functional requirements without having some frame of reference. Just think of a car you would like to have. You can describe the high level requirements, but until you go to the lot and take a test drive, matching those requirements to a make and model is really a guess.

What ideas do you have for combining traditional and agile methodologies? Please feel free to share your ideas here.

(To control spam, all comments are moderated)

 

Data Entropy

Entropy, in scientific terms, is the tendency of system to progress toward a state of disorder. The information of organizations is one of the best examples of this, and while tools like SharePoint can provide a framework for combatting this, it is not in itself capable of preventing it. The only thing capable of maintaining the order of information is a well thought out governance system that is administered and adhered to.

In my days as a field engineer in nuclear power plants, governance of information, aka document control, was vital to building, maintenance and safety of the plant. A single, controlled hard-copy of each document resided in one place and could only be released to individuals authorized for that document. Information Only copies were available to a larger group as necessary, but work was always done according to the controlled copy. The documents included designs, procurement records, policies and procedures and more, and there was a trail between them. You could look at a design document and tie it back to a procurement document and a procedure. This enabled one to find out something as seemingly minor as the supplier of a screw on an assembly, the date it was purchased and by whom. And this was all on paper!

Because electronic documentation is so much easier to produce and share than paper, the tendency toward entropy is greater. Implementing systems of governance are bound to be met with resistance as people will perceive it as a way to slow down their work.  But the hours lost looking for documents, or working from the wrong documents more than make up for any inconvenience created by governance for most organizations.

How to do Everything in SharePoint

How to do Everything in SharePoint 2013

After being selected to manage a implementation of SharePoint 2013, I needed to come up to speed FAST on what has changed in SharePoint since I last touched it in 2007. After sampling several books on my Kindle, I settled on Stephen Cawood’s How to Do Everything in SharePoint 2013, and it delivered. Cawood presents a rich overview of all of the features in SharePoint, along with screenshots and examples from a users perspective. He spends some time going into Administration and Development, but that is not the focus of this book. 

If you’re new to SharePoint, I would highly recommend this as a place to start to quickly understand what the product has to offer, as well as how to navigate and start using some of the many features of this latest release from Microsoft.

Pilot Large New or Complex Projects

A Data Warehouse Effort

A marketing company undertook a project to build a data warehouse to house all of its clients data for the purpose of analysis and producing direct mail files. The project was daunting – 120 different clients on a variety of platforms and a data warehouse hosted by a third-party. 

The project plan called for all of the clients’ data to be onboarded in three waves. The first small wave consisting of a handful of clients, a larger second wave, and a third final wave for the balance. All of the clients were expected to be in the data warehouse within 16 months. After the initial load into the data warehouse, clients would then update their data as often as weekly to keep the warehouse in sync with the client data.

Warning Signs

The difficulties began almost immediately. The level of expertise at the client level about their own databases was low and their data was often unreliable. It had to be mapped to the standard structure of the data warehouse, and the fit was not always obvious. The first wave was scaled back while onboarding continued with the second wave. Limited resources were dealing with problems not anticipated causing frustration for the clients and the company’s staff. The push continued to get all of the clients’ data in-house while still doing the proof of concept with the first wave.

Backtracking

Ten months after the start of the project, the proof of concept with the first wave was completed and failed. Management decided to start over and validate the clients in the first wave, and apply the lessons learned to those in the second wave. Onboarding of the clients in the third wave was put on hold until the second wave could be completed. Sixteen months later, support for the project from clients and staff were dropping and costs were rising. The project continued with the hope of recovery down the road, with no true road map for completing it.

Lessons

Once the complexity of the project was understood, further phases should have been put on hold. Naturally, knowing the complexity in advance would have meant not scheduling the next waves until a proof of concept was completed on the first few clients. Also, additional operational tasks needed to be accounted for and put back into the costing and scheduling models, but weren’t, while management focused on sunk-costs as a reason to continue.

It takes courage to cancel a project and there are certainly times when that is necessary. The damage done to clients and personnel when a project doesn’t go well can be irreversible. To reduce risk, take on smaller pieces, document findings, evaluate and then decide whether or not to continue.

Planning Processes – Part 3

Project Time Management will be the topic of this installment of the Planning Process Group from the PMBOK. These processes consist of:

1. Define Activities
2. Sequence Activities
3. Estimate Activity Resources
4. Estimate Activity Durations
5. Develop Schedule

My personal approach to these is to work directly in Microsoft Project for all five of these processes, allowing them to build on each other, adding increasing detail as it becomes available. To Define Activities, it is necessary to refer to the scope baseline for the project, and then seek input from past projects, including possible templates, and input from experts, including the resources who may be doing the work. If you are working in Project, the output is a simply a list of activities with no logic, durations or dates. If you’re not using Project, this same list could be kept in a spreadsheet.

The activity list is a comprehensive list including all schedule activities required on the project. The
activity list includes the activity identifier and a scope of work description for each activity in sufficient
detail to ensure that project team members understand what work is required to be completed.

– PMBOK 4th Edition

Sequencing activities requires a thorough understanding of how the work can be performed, and an idea of the kinds and numbers of resources that will be available. I am departing from the PMBOK here a bit, as in the strictest sense, you wouldn’t estimate activities until the next step. But if you already know that you are limited to one particular kind of resource, it doesn’t matter if that resource’s work could all be sequenced in parallel. By recognizing this early, you will arrive at a more accurate schedule sooner.

Once you have your activities sequenced, you can begin estimating resources. Again, if you are using Project or Primavera, you will start building your resource list directly in the tool. Microsoft Project enables one to input resources directly from the Outlook Global Address book which has many advantages, especially with the Professional version that is tied into Project Server. Even without that though, using this techniques prevents the accidental entry of duplicate resources due to misspellings. At this point though, you may be entering generic resources such as Programmer which can be replaced later with an actual assignment.

The resources from your list are then assigned to each activity with an estimate of the amount of work that activity will take to complete. This is Estimate Duration process. The first step is to have your calendars set up along with any special resource calendars. The ideal way to do this in Project is enter Work, not Duration.  (Note: if using MS Project, this is a critical point in the development of the schedule. How the task is set up before the resource is assigned will affect the way it behaves when progress is reported, duration changes or resources are added. If you are not familiar with Task Types, take some time to understand and experiment with them. This will save you hours of frustration later.)

If you have been entering all of these data into Project, you now have a raw schedule. If you have sequence every activity, then you also have a Critical Path. Despite this, the work is not done.  Do you have any resource over allocations? Then you need to level. Are there other resources available that you haven’t considered? Maybe you can crash the schedule. Are there any finish to start activities that could be done in parallel? You have an opportunity to fast track the schedule.

The schedule is never really finished until the project is, but if you follow these steps the changes along the way will be easier to make, understand and communicate to the project team.

Planning Processes – Part 2

In this part of the series on Planning Processes from the PMBOK, we will examine the three processes associated with the Project Scope Management knowledge area. They are:

• Collect Requirements
• Define Scope
• Create the Work Breakdown Structure

Of all the Project Management Processes, Collecting Requirements is, in my opinion, the most difficult and the most vital to a successful project. On the surface, collecting requirements is simple and the PMBOK offers eight different Tools and Techniques for doing so (see section 5.1.2 of the fourth edition). The problem is that most people do not know what they do want until they get what they don’t want, or at least see a facsimile of what they thought they wanted. That is why a combination of interviews, workshops and prototyping offers a better chance of achieving project objectives than any single approach to collecting requirements.

The outputs from collecting requirements are three documents: the requirements themselves, a requirements management plan and a requirements traceability matrix. The requirements management plan establishes at the beginning of the project how changes to requirements will be managed, tracked, reported and approved. The traceability matrix follows each requirement from its conception as a business need, through its technical development, then testing and finally, acceptance. An Excel spreadsheet is usually used for this purpose.

Section 5.2 of the PMBOK addresses Scope Definition. Once the requirements are defined and documented, decisions need to be made about what will or will not be part of the project. The Project Charter will guide that decision, but it will also be influenced by budget, available resources and competing projects in the organization.

Once the requirements and scope are established, a Work Breakdown Structure (WBS) can be developed. With the major deliverables defined in the requirements document and scope statement, the project deliverables are then broken down into smaller, more manageable units. This process is called decomposition. The deliverables are decomposed until the reach a level that represents a work package. This is the lowest level in the WBS, and is the point at which the cost and activity durations for the work can be reliably estimated and managed, and where resources and budget are assigned. In a large software project, that could be as large as Design User Interface, or as small as Build Login Screen – it depends on the overall size of the project. In general, smaller is better, but only to a point. The smaller your work packages, the more of them there will be and that will require more frequent updates to the project plan.

Planning Processes – Part 1

The PMBOK connects 20 processes to the Planning Processes Group. In this first part of the series on Planning Processes, we will look at the foundation document, The Project Management Plan.

The PMBOK lists four inputs to The Project Management Plan:

1. Project charter
2. Outputs from planning processes
3. Enterprise environmental factors
4. Organizational process assets

The project management plan becomes the primary source of information for how the project will be planned, executed, monitored and controlled, and closed. So what should go into the document to accomplish this? Here is a typical table of contents that you might see in a Project Management Plan:

Overview
Project Purpose, Objectives, and Success Criteria
Project Deliverables
Assumptions, Dependencies, and Constraints
References
Definitions and Acronyms
Updating the Plan
Project Organization
External Interfaces
Internal Structure
Roles and Responsibilities
Managerial Process Plans
Start-Up Plans
Estimation Plan
Staffing Plan
Staff Training Plan
Resource Acquisition Plan
Project Commitments
Work Plan
Control Plan
Data Control Plan
Requirements Control Plan (or Scope or Change Control)
Schedule Control Plan
Budget Control Plan or Financial Management Plan
Communication, Tracking, and Reporting Plan
Metrics Collection Plan
Risk Management Plan
Issue Resolution Plan
Project Close-Out Plan
Technical Process Plans
Process Model
Methods, Tools, and Techniques
Configuration Management Plan
Quality Assurance Plan
Documentation Plan
Process Improvement Plan

After the plan is completed, it must be communicated to all the stakeholders and accepted up and down the management chain. The document then becomes a road map for all aspects of managing the project. If your organization has a Project Management Office, it will have a template with most of these items prescribed with only a few variables from project to project.

The most important thing about the Plan is to use it! It must be followed and referred to often for projects to succeed. Too often I’ve seen well written plans forgotten shortly after the project begins. Naturally, situations arise that also call for the need to be flexible, but recognizing when you are varying from the plan gives you information to create a better plan for your next project.