EPM, Microsoft Project and You

BY:  Collin Quiring

One of the mantras of Project Management is COMMUNICATION.  Study after study shows that one of the consistent reasons for failure of a project is a lack of or poor communication.  This goes for both positive and negative information.  December was spent on holidays and dealing with the fact that bad news does not get better with age.  Rather than being told there was an issue and trying to help resolve it, I have spent my time trying to understand and adjust to the effects of the issue.

I think it is human nature to try and gloss over rough edges or to avoid tough conversations about issues that will be taken negatively.  However, the statement “Bad news does not get better with age” still applies.  When somebody avoids the tough conversation they might be making life easier on themselves for the moment, but it will probably only get worse as time goes on.

I once worked with a company that had a culture of avoiding negative issues.  This was strongly encouraged by management in the way they dealt with each other and with employees.  This only meant that more money and time was spent fixing issues that had become critical and unavoidable – when they could have been addressed much sooner during the project.  Most issues were seen early in the life of the project and if those that knew the information were encouraged to speak up, rather than punished, they would have become true partners in fixing the problems.  That company would be stronger today since it would have an employee base that was “bought in” to the company and were “part of the solution”.  Instead, as the economy got weaker, and more potential issues arose, the employees ran for cover, which created more issues and so on and so on.  The same concept holds true for vendors, customers and contractors. 

We all know that 2009 was a rough economic year for many companies.  Some managers/owners have shared the bad news of financial downturn with employees – ranging from pay cuts, to cutting all “discretionary” expenses (another post on that some other time!) to forced time off without pay; or, ultimately, layoffs.  Some have kept the bad news secret and then end up at the same point.  In these two cases, the facts don’t change but the ability of the employees to help does.  Even banks have come to the realization that it is better to work out new terms with loan customers than to foreclose on every mortgage or business that they can – because it is better for everybody in the long run.

A lot of companies won’t share bad news because they fear the consequences – some real and some perception.  They want to look strong and that they are weathering the economic storm.  However, when a company knows it is having a hard time, it should go to its vendors, customers, employees and contractors and ask for help.  I know of some companies that have gone to their vendors and asked for restructured payment terms.  I know of companies that have talked with contractors and employees about modifying work or payment structures, or any of a myriad of other options.

I also know of companies that have pretended all is well and then just not paid vendors.  I know of companies that have said everything was going great and then they shut the doors.  How many of those cases would have worked out if they had shared the bad news sooner?  Yes, some companies would still go out of business, and yes, admitting a problem sometimes creates additional issues.  However, what of the reputation of the company and management when they don’t admit to issues and end up having to shut the doors?  And, what about when people eventually find out there is an issue – it may be too late to correct it at all and it is possible that a vendor that could have helped weather the storm becomes the catalyst that forces changes nobody wanted (including the vendor).

Bad news does NOT get better with age!  If a company is experiencing issues, they should be honest enough to confront it themselves and then determine a communication plan.  That plan might be to tell only tell a select few vendors, contractors or customers.  It may be that if one or two big customers pay a little faster and one or two vendors accept getting paid a little later that everybody can weather the storm together.

BY:  Collin Quiring

For those that may be getting this blog’s RSS feed but don’t visit our website very often I am sending this out as a quick note.  We have added TWENTY-EIGHT documents to a new White Paper page on our website.  At this time, the majority of them are on Microsoft Project but there are some on Microsoft Portfolio Server as well.  What makes these unique is that some of them are meant to explain in detail the BUSINESS REASON to set something up.  For example, the document on Understanding Project Server Cubes isn’t a technical document, it is an explanation of what the cubes are and what they do.

For those interested, here is a listing of the documents we just added:

Accepting Updates in Project Server 2007
ActiveX Work Around for Project
Activity Creation in Project Server 2007
Administrative Project Check In for Project Server 2007
Checking In a Project with Project Professional 2007
Setting up Document Alerts in Project Server 2007
Enterprise Resources in Project 2007
The Enterprise Global File and the Standard Template in Project
Exam Summaries for Microsoft Project Certification
Linking Projects in Microsoft Project
Schedule Movement – Dates that Represent Actual Information
Resources Assigned to a Task
Installing Outlook Task Synchronization with Microsoft Project Server
Using Outlook with Microsoft Project Server Documents
Project 2007 – Professional and Server – New Additions
Connect Project Professional to Project Server
Proposals and Activities Defined
Proposal Creation in Project Server
The Difference Between Save, Save As and Publish
Task Drivers in Microsoft Project
Templates – Creating and Using
Updating a Task in Project Server 2007
Using Visual Reports in Microsoft Project Professional
Using the Outlook Add-in for Project Server 2007
Project 2010 and Project Server 2010 Highlights
Creating a New Project in Microsoft Portfolio Server 2007 – Part One and Part Two
Understanding Project Server Cubes
Viewing a Project in Microsoft Portfolio Server

Just go to www.PMPSpecialists.com and select the “White Papers” section.

BY:  Tanya Foster

Two great products… each one has its own specialty, but so many people try to use them interchangeably.  I can’t tell you how many times I have seen people using Excel to schedule their projects.  Don’t get me wrong, Excel is a great tool, but not necessarily as a scheduling tool.  Project can do so much more for you regarding scheduling, resource management, cost, etc. than Excel can.  And I’ve also seen people using Project no different than an Excel spreadsheet.  Both of these products has their own special bells and whistles.  Project has so many bells and whistles it’s hard to even know where to start with a list! 

One of the things that Project can do that Excel can’t is reschedule your work for you.  You tell Project how long the task should take, who will do it, and the actual start date, and it will reschedule that task if it needs to be.   Now… could you do that in Excel? Sure… but it’s manual, whereas Project does this automatically.  You can create an entire work breakdown structure with dependencies in Project.  Can you do this in Excel?  You can create a work breakdown structure, but the dependencies would be more difficult.  Once you have your work breakdown structure in Project, all you do is determine which task is dependent on another one and click a button.  Maybe you really like the reports that Excel gives you.  You can do some of those same types of reports in Project.  Or if you have an Excel formatted report that you just can’t live without, you can even export your data from Project into Excel and then create the same reports that you’re used to.  That way you can let Project do the scheduling and use Excel to view and report on some of the data.

I’m all about keeping it simple!  If I try to use Excel for any type of scheduling I typically spend more time and energy doing manually what Project can do for me automatically.  Save yourself some time, energy and money!  If you currently schedule with Excel, take a trial run at Project and see what you think.  I think you’ll be glad that you did!

BY: Tanya Foster

I was able to attend the PMI Global Congress this year.  I always enjoy this conference.  You get to network with so many people and it’s nice to get to see some of the faces behind newsletters, blogs, etc. that I read.  One thing I did this year that I haven’t done at this conference in the past is to “tweet”.  Yes, you read it right… I said “tweet”.  For those of you who don’t know what tweeting is… it’s updating your status on the ever popular social media site Twitter.  You basically just type in what you’re doing, in 140 characters or less, and send your tweet to your followers.  They can read your tweet, send you direct messages, etc.  So Collin and I were playing dueling tweets this year.  We were only in the main sessions together, but whenever we were, it was a race to see who could tweet the fastest!  Usually he won, but that’s ok.  It’s the content that counts, not the speed! J

After the first night of the conference was over, I logged onto Twitter from my trusty laptop and searched for some others that were tweeting from the conference.  I found several, so I started following them (on Twitter, not at the conference! I’m not a stalker!).  During breaks in the conference, I would read everybody’s tweets from my phone.  I got to where I really looked forward to reading some of them and finding out what other people were doing at the conference.  Then it just so happened, that I attended one of the sessions and low and behold, there were several people whose names I knew, but had never met.  This session was on social media and there were several presenters, one was a fellow tweeter, one wrote a blog that I read all the time, the other does a podcast that I listen to.  It might sound kind of silly, but it was almost like they were famous!  I wanted to go up and meet them and tell them how much I enjoy their tweets, blog and podcast.  If I’d have been thinking clearly I would have had them sign my autograph hound!

I really enjoyed most of the sessions that I went to this year.  There were a couple that were just outstanding, but all in all, I think I was able to learn something in every one that I attended.  I like to go through the exhibit hall and see the different things that are set up.  I also take a free pen from all of the booths that have them so that I don’t have to buy any for next couple of years!  Hey… it might sound silly, but some of these pens are awesome! This was a very good conference and I’m really glad that I was able to attend.

BY:  Collin Quiring

Just because I have changed the oil on my car nobody would believe that I am a mechanic.  I understand debits and credits, but nobody would call me an Accountant.   And, just because I have worked on a Project, or part of a Project, I am not a Project Manager.  It seems to me that there is a disconnect that many people and organizations have when it comes to Project Management.

I have been thinking about how this logic doesn’t seem to be resonating with many individuals and organizations.  It seems to happen most often in the Information Technology area but it happens in all areas of a company.  There is some work that is assigned to a person and whether they do some, most or none of the work, they are held responsible for the end result.  The outcome notwithstanding, the work comes to an end at some point and either the company or the person assigned suddenly believes that they are a Project Manager and that they do that thing called “Project Management”. 

I have seen where somebody does a significant amount of work in a key area of a project and because they had the majority of the deliverables and were central to the project, they start to think of themselves as a Project Manager.  With no “true” Project Manager, they are a key person and they do end up leading most meetings and giving status reports – formally or informally.  So, the person and the company start to believe that this is Project Management.

This both amuses me and saddens me because it hurts everybody involved AND it hurts the reputation of Project Management in general.  The person who is now viewed as a “Project Manager” is given projects and they don’t necessarily have the skill set (or desire) to be a full time Project Manager.  If they don’t succeed, then both they and the company can come to view Project Management as something that just doesn’t work.  If they do succeed, then they both start to believe that this whole Project Management concept is simple.

There are professions that some organizations and individuals don’t fully realize can be done so much better by trained, competent people (like Project Management, Business Analysis, Human Resources, Bookkeeping, and Purchasing).  We need to better educate management about what Project Management truly is and does and the value of it in general.  And, we need to encourage those individuals that are “Project Managers” to get the training and expertise to do that thing we call Project Management.

Most companies will not do their financial reports without an Accountant and they won’t take care of legal matters without a Lawyer.  We will know that we have arrived as a profession when a company wouldn’t work on a Project without a Project Manager.

BY: Collin Quiring

This is a quick primer on the difference between a summary task and a milestone task. 

In the Project Management Body of Knowledge (PMBOK), version four, the term “Summary Activity” is defined as:  “A group of related schedule activities aggregated at some summary level, and displayed/reported as a single activity at that summary level.”  And, a “Milestone” is defined as “A significant point or event in the project.”

A milestone is usually used to indicate when a specific phase or group of tasks is to be completed.  It can be considered a deadline date.  It is possible to have numerous milestones in a schedule.  While a milestone can be assigned a resource that is responsible for its completion, it is more common to use the milestone without resources.  This is because the milestone is often a successor to a number of other tasks that all have to be completed prior to its completion.

In Project Professional, a milestone is what the system automatically creates when a task is given a zero duration.  To add a deadline date to the milestone task there is an option to add that date in the task information.

A summary task is just that – a task that summarizes another set of tasks.  Normally, the summary task is not assigned a resource.  This is because the summary task’s start and completion dates are derived from the earliest subtask’s start date and latest subtask’s finish date.  As each task is completed, the summary task’s overall completion is updated as well.  Normally, a summary task is not linked to other tasks.  Using summary tasks makes reading a WBS (Work Breakdown Structure) easier when using a logical grouping.  Creating a WBS usually involves determining the summary tasks and then the subtasks to complete them but it is possible to put all the tasks into a WBS and then determine the summary  tasks later.

In Project Professional, the subtasks are indented and that makes the summary task bold and outdented.  Many levels of summary and subtasks can be created.

Just as a reference point, here are the definitions as defined by Microsoft.  For Microsoft Project, a milestone is defined as: “A milestone is a reference point that marks a major event in a project and is used to monitor the project’s progress. Any task with zero duration is automatically displayed as a milestone. You can also mark any other task of any duration as a milestone.”  And, a summary task is defined as: “When organizing the tasks for a project, you can group the tasks that share characteristics or that will be completed in the same time frame under a summary task….You can use the summary tasks to show the major phases and subphases in the project. Summary tasks summarize the data of their subtasks, which are the tasks that are grouped beneath them.”

BY:  Collin Quiring

Project Professional 2010 and Project Server 2010 come with great modifications and an improved user experience.  Part of that is to allow all sorts of flexibility in many areas of the tool.  While this is a good thing for many reasons, there is one area that has concerned me since starting to review the first versions of the 2010 version.  My concern isn’t specific to Project (or any specific 2010 product either) as this has been around for years but it seems to be a bigger issue with each newer software release and the 2010 release really brought it to the forefront of my thoughts.

The question that keeps lingering in the back of my mind is:  What do you do when best practices and the capabilities of a tool collide?  “Best practices” being broadly defined as whatever the organization considers their best practices, whether derived from their internal processes, industry standards or bodies of knowledge.

One answer is just to turn off or otherwise disable the capabilities of the tool.  That isn’t always possible or easy to do though.  And, almost every time I have done that it doesn’t take long for somebody to wildly protest that they need either that capability or a corresponding one that no longer works correctly.  Constantly reviewing “best practices” is valid as well but that never results in every capability suddenly becoming acceptable usage.  Another solution is to train everybody in the way that you want them to do things – which seems to work better in theory than reality.  It isn’t easy to force people to use a tool the way you want them to use it.  .

Some might say that you shouldn’t force people to use a tool a certain way – but, of course, we do that every day.  How many companies use a note field as a valuable reporting field and require certain characters to be put into the field in a certain order?  Or, how much variability do employees have when reporting their time for weekly payroll?  How many variations are there in Outlook to book a conference room – and yet every company I have been to has only one way to do it “right” so that it is actually reserved.

It is almost counter-intuitive but the more capabilities a tool has, the more administrative work it requires.  The administrators have to understand all the various input possibilities and deal with how that information is stored and used.  Reporting and views have to be created that allow for all the variables (even if some variables aren’t “allowed”). 

I don’t have a definitive answer to the question but as I struggle with how tool capabilities affect best practices I would love to hear if somebody has a great solution.

By:  Collin Quiring

In trying to set up schedules, one of the best ways to find out how much time is needed for a specific task is to ask the person doing the task.  And, one of the worst ways to get an accurate amount of time is to ask the person doing the task.  More often than not, when asking the person that is assigned the work how much time they need to complete their task, they will give a padded number – sometimes significantly.

Why?  Is it that they don’t really know how long it takes?  Is it that they are born liars?  Is it because they want free time and hope that you will build it into the schedule?  The answer to all of these is a resounding “No!” 

It seems that Resources (what Project Managers like to call people) have a few concerns about answering the time question.  Usually, a Resource has multiple projects that they work on.  And, they have overlapping work from those projects.  And, they have non-scheduled time (from mandated training to watercooler discussions).  And, they are given conflicting priorities.  And, and, and, and….. 

So, what are they often doing when they give a time estimate?  Are they padding the time unrealistically?  They might be padding it a bit but I think that most people add up the “and’s” of their work life and they come up with a relatively accurate time estimate.  The disconnect seems to be between the Resource and the Project Manager (or Resource Manager).

The Project or Resource Manager wants to know how long it will take to do the task in THE schedule of the moment while the Resource is providing how long it will take due to ALL of their work.  There are lots of “solutions” to resolve this problem– some technical and some business or company cultural.  However, I submit that the core issues are not resolved and that we tend to address the symptoms. 

The root causes of the problem seem to me to be trust of each other and understanding.

Part of the reason that the Resource gives seemingly extreme time estimates is because they have learned that if they give a short time frame, the Project/Resource Manager will hold them to it regardless of other work or variables.  And, from the other perspective, the Project/Resource Manager has seen the Resource do this work “in less time than that” but doesn’t seem to understand that there were other tasks neglected to do so.  (And, Project Managers have learned that at the start of a schedule it is easier to have an unrealistically short deadline and then deal with missing it when the time comes than it is to tell the sponsor from the beginning they can’t meet the deadline – but, that is a different post.)

How can this tidbit of knowledge improve scheduling?  If we would just sit down and sing Kumbaya together the world of scheduling would be a better place.  Ok, maybe not.  But, the way to immediately improve scheduling is to try and understand the capacity and utilization of a Resource.  From the Resource’s perspective, they would need to give estimates that are “in a vacuum” – a time estimate for how long it takes to do the work, if that was all they did.  The Project/Resource Manager needs to understand and compensate for variables that affect the time estimates for THE schedule by accounting for ALL work.  With a real time estimates and a schedule that can move with the changing realities of work, a schedule can become a powerful and accurate tool.

Easy to say, difficult to do. 

However, we have found when working with customers that getting to this point has always paid off. 

I think about the phrase “We never have time to do it right the first time, but we always have time to do it again.”  Perhaps, if we trusted each other and extended an understanding of work realities we would have done it right the first time because we would have scheduled enough time.

By: Tanya Foster

So… have you heard about the mega whoosh lately?  This video is causing quite a stir on the internet.  There is a lot of discussion around whether the video is real or fake.  Here’s the background: German engineer Bruno Kammerl created a type of material that he calls Softslide.  He describes it as “almost frictionless.”  His goal is to build the longest waterslide in the world.  So he creates a website, uses Microsoft Project to detail his schedule, conducts tests and uploads videos to YouTube to document his progress.  He had been searching for investors when along comes an investor who provides him with the means to test his water slide in the German Alps.  Check out the test video below!

Amazing right?  Well… maybe not.  According to one website I read, they have stated that they verified it “was a carefully crafted viral ad for Microsoft Project 2007”.  There is still a lot of speculation and only this one site has come out and stated that they had verified that it was fake.  Now I don’t know… the video looks pretty real to me, but I’m no expert on computer tricks and graphics.  If it is just a clever Marketing tactic, I have to say it’s a pretty good one!  This video has gone “viral” and continues to get thousands of hits every day.  It’s created lots of discussion and Microsoft is mentioned in most of the posts that I have read whether the post is positive or negative… they’re still getting the word out on Microsoft Project.  I did go to the actual site and Bruno does have some screenshots of his project plan on there and does a great plug for Microsoft Project.

So… tell us what you think and why.  Marketing tactic or real project?   (Either way… I still enjoy the video!)

By:  Collin Quiring

When starting a project, everybody involved has a set of assumptions that they bring about the project.  Some are about how it should be done, how best to do it or who should do it and so on and so on.  But, there are another set of assumptions that I will call “Pre-Project assumptions”.  Some people might even consider these “givens” or “obvious” and not assumptions at all.  Culture (any type – organizational, geographical, etc), philosophy, personality type(s) and a myriad of other work and non-work variables produce pre-project assumptions .  And, usually these are the non-spoken, non-discussed part of the project.  Sometimes, as my airplane example below shows, they are celebrated by an organization as a market differentiator.

Even though these are hidden, pre-project assumptions affect every project that the organization does.  And, it affects the project BEFORE the project ever gets going.

Here is a high level example to better explain what I mean.  If a Project Manager is tasked with a technology project to “Add a new server” to the company’s computer system there a whole set of assumptions that affect the project before the PM starts looking for more detailed information.  Some of those pre-project assumptions might be:

1.       Since we are a Unix based computer center, we will add another Unix server.  (Or, Windows Server for a Windows based center, etc.)

2.       This new server will be for a business application.

3.       Since I am the PM and I don’t work in procurement, “Add a new server” means I only have to worry about the software and application and not the hardware.

4.       I know a certain operating system better than the others, so that is the one I will make work with this new server – no matter what.

(Not all pre-project assumptions are bad to have – like assuming that adding a new server at a company is for a business application and not for those wanting to play Halo online.)

So, what’s my point?  Well, pre-project assumptions affect every project – and need to be addressed!  A Project Manager needs to know what they (and other stakeholders) are assuming from the very start and so should the team members.  There may be quick, easy and solid agreement among the team about what those assumptions are – but it should be discussed.  Some pre-project assumptions are naturally discussed as the project is assessed (like the operating system might be determined by the server type), but most are not talked about.

What got me thinking about this in general is an example of pre-project assumptions with deadly consequences.  After the crash of Flight 447 on June 1, 2009, I learned about a critical set of pre-project assumptions that Airbus believes in.  They have the philosophy that technology is less fallible than human intervention.  They believe that the technology of the plane should override the pilots’ actions – or make it very difficult for a pilot to make the “final decision” about any action.  This is not the philosophy of Boeing.  The Boeing philosophy is that the pilot can easily override the technology of the plane.  (At the time of this writing, it is widely believed that the plane crashed mainly due to computer malfunction.)

So, when a Project Manager at Airbus is asked to “Build a Plane” they have the pre-project assumption that the technology put into the plane can’t be overridden by the pilot.  This affects the decisions of the project before the first work package is every built or a schedule is put on paper.   The same project at Boeing to “Build a Plane” has the opposite assumption.  The pre-project assumptions that each company has affects the cockpit design, the control systems, displays and other features.  These can have life-and-death consequences.  People can argue amongst themselves about which assumption is right or wrong but this is one assumption that affect how each company builds a plane.

Think of this from a customer point of view.  If you are an airline about to purchase a new airplane it would be good to know about this assumption because it affected the design of the end product.  Both manufacturers have similar technology on their planes that does the same basic functions so this isn’t about who has the better wiring.  And, this philosophy may not be reflected in the final price of the plane or a visual difference between the two planes, but the pre-project assumption affects how the plane works.

While most Project Managers don’t deal with life-or-death pre-project assumptions, they do bring a set of assumptions with them that affect the end product.  The assumptions might be subtle, they may affect only the schedule and not the end product or it may be obvious to the end customer.  Either way, the pre-project assumptions should be addressed because they will affect your project!

Review Source:  http://www.seattlepi.com/business/boe202.shtml