EPM, Microsoft Project and You

Enterprise Project Management, Microsoft Project Professional and Microsoft Project Server

  • BY: Collin Quiring

    Our book has been published!  It is titled “Mastering Resource Management: Using Microsoft Project and Project Server 2010″ and was written by Tanya Foster and Collin Quiring.  It was written to be an effective tool for Project Managers and Resource Managers who use Microsoft Project (whether Standard or Professional) and for the Project Managers and Resource Managers that use Microsoft Project Server.

    It can be found at www.Amazon.com, www.BN.com (Barnes and Noble), www.jrosspub.com (J Ross Publishing) and other book selling sites.

    Here is the high level summary about the book:

    In the new economy, organizations in a myriad of sizes and industries are now more than ever seeking a better understanding of how to best utilize and manage the scarce resources devoted to their project portfolios. Microsoft® Project and Project Server are the most widely used and one of the top-rated enterprise project management software packages in the marketplace today and understanding how to properly use it allows an organization to cut costs, share information, and increase efficiency and effectiveness. However, due to the size and complexity of the software, covering all the numerous features, within a single text, may not meet the needs of those specifically involved with resource management.

    Mastering Resource Management Using Microsoft® Project and Project Server 2010 provides the guidance needed to master resource management and exploit the full potential of Microsoft® Project and Project Server as it pertains to this critical function. It will also serve as a great companion to practical guides demonstrating the breadth of features and functionality available in this software.

    Key Features:

    • Presents step-by-step illustrated instructions on using Microsoft Project with Project Server 2010 as well as stand-alone Project Professional to best utilize and manage scarce resources devoted to project portfolios
    • Explains the philosophy and methodology the software tool uses “behind the scenes” which will enable you to use it with confidence and clarity, become an expert user, and better manage your project portfolios and business
    • Provides practical insights into how to maximize the resource management capabilities of Microsoft Project to obtain better information on resource usage, costs, and future needs, and in turn, gain better planning, scheduling, awareness and control of your scarce resources
    • Highlights the things a manager must remember to do daily, weekly, monthly and annually to keep the system in place and working as expected
    No Comments
  • BY:  Collin Quiring

    I am not a pilot, nor do I play one on tv.  However, I have a number of friends that are and I have had the joys(?) of travelling quite a bit by plane in the last few years.  I have also flown on charter flights and that is a different experience than flying commercial as well.  When I flew charter, the pilot allowed us to listen to the communication between the various control centers and he took some time to explain what the handoffs were about.  And, like every industry there are numerous acronyms and terms with their own in-house meanings.

    Recently, I was on a commercial flight into Chicago.  Everything was normal and uneventful.  And then, just before landing, a few hundred feet or less, we accelerated and took off again.  We never touched the ground but we sure came close.  After a few minutes, the pilot came on and said we had “been brought in too high” and that we would try again and be “on the ground in five minutes”.  Whether or not I believe that as the real reason is for another day.  However, it definitely took more than five minutes to get back to landing – and EVERYBODY who has ever flown before KNEW THAT IT WOULD!

    On the next flight, when we left the airport, on United, the pilot told us that if we listened to a certain station on the airplane provided music and talk channels we could hear the pilot and air traffic controller discussions live and unedited.  I listened to this and while I didn’t understand all the terms it was interesting and added to my learning about how the communication works.

    As I often do, I tied these experiences back to Project Management.  I had two great examples of Project Management in in the space of two hours and a third example from previous experiences.  First, the aborted landing – I was in the plane, had no idea why we aborted the landing, didn’t necessarily believe the reasoning given and absolutely never believed we would be “on the ground in five minutes” (which proved true about 20 minutes later).  My trust in the pilot never wavered and I like to believe that it was the pilot’s wisdom about issues on the ground that kept us from landing (but, for all I know, the pilot didn’t put the landing gear down and that tour was screaming at us to not land).  So, the communication from the pilot after we accelerated was lacking and seemed both polished and standardized to make all sound fine.

    The second example is the ability to listen to the flight communications.  I still have no control over outcomes or methods and don’t even know all of the terms being used BUT I had more of a feeling of “empowerment” and that just listening helped me better understand what was happening.  The third example is the first one I mentioned above – when I flew charter and the pilot not only allowed me to listen but explained what I was hearing and what it meant.

    We hear again and again and again and again that the mantra of successful Project Management is COMMUNICATION!   And, these examples reminded me of this again as well.  The terms and acronyms that we use in Project Management have meaning to those of us that use them.  But, our team members may have no idea what we are talking about.  Also, they may not have had exposure to a Project Manager and “project-management-ese” language before.  And, if we have meetings (with or without the team) where we don’t explain the results and at least some of the reasoning to the entire team then we lose their trust.  If we don’t communicate the realistic situation then we also lose their trust – those of us who have had to circle in an airplane know that nothing happens in a mere five minutes!  This is just like telling team members or stakeholders that “we are over budget and late on the schedule, but we will catch up in time without any problems”.  Anybody who has been on a project before has every reason to doubt this statement.

    I know that not everybody always knows (or should) everything about a project but the more open we are and the more realistic we are in our communication the more the team and stakeholders will trust us and that only helps our projects!

    No Comments
  • There are a lot of articles, blogs and even some books about how Project Manager’s should be selected.  Also, stories abound about how people find themselves in the role of Project Manager because “they were there” or by some other fortunate series of events (or some would say, misfortune J ).   The same is often said for the team that is assembled – they were there, or they were the only people available or whatever other criteria was used to choose them.  Unfortunately, in many cases, the team and the Project Manager are chosen not because of skill sets or abilities but due to any of a thousand different reasons.

    My son and I have been enjoying a television show on the History channel called “Top Shot”.  This is yet another reality show and in this one 16 people from around the United States compete for a $100,000 and the title of being “The Top Shot”.    They go through various team and individual challenges where they use different weapons (firearms, bow and arrow, tomahawks, etc) and people are eliminated.  A key piece of information is that the worst marksman is NOT necessarily the one eliminated.  The best marksman is NOT necessarily the one that is the most likely to win.

    How does this apply to Project Teams?  I was thinking about the way the 16 people were initially chosen.  Basically, anybody that wanted to be on the show could apply (with a list of rules and legalese with some simple requirements – like never having made terroristic threats).  As a participant, you must have skills in the area of marksmanship.  I was thinking that this would be a great way to obtain the Project Team – have folks volunteer!  But, then reality sunk in and I realized that getting volunteers to form the team for a project are few and far between.  And, the prospect of giving one team member a prize of $100,000 for being on your team seems unlikely.  It would be great to get the people with the correct skills to volunteer for a project.  Barring a great bank of volunteers trying to get on a project, at least having a known skill set pool to help select from would be great.  And, some sort of criteria, other than immediate availability, for how a person gets on the team would be beneficial.

    What about the Project Manager?  I have only watched Season Two of Top Shot but assume that the way the group leader’s were selected on Season One is the same as this season.  The best two marksmen in the very first competition become the Team Leaders.  Those Team Leaders then pick their teams from the other 14 participants.  One of the two new Team Leaders interviewed everyone and made a list of how he would rank the team members based on his own criteria.  The other team leader seemed to only talk to a few folks, get their opinions, and then decided on a few key people that he wanted and the rest kind of fell into place.

     In Top Shot, the method of selection for the team leader is a bit random and a bit selective, or specific.  First, the “specific” part – every one of the 16 people are highly skilled marksmen and they all have passed the requirements to be potentially selected as the lead.  Therefore, from a purely skill set perspective, they are all relative equals.  However, the random part is that they all had to use a weapon that they no doubt had never seen before and had to hit a target – and the “best” or “most skilled” marksmen may not have shot the closest to the bull’s-eye in this one event.   And, being the best skilled on this one occasion or being the best skilled overall doesn’t necessarily make a person a leader.  To me, this is very like picking a Project Manager based upon who came into work on time or early on the second Tuesday of the month. 

    This does have me thinking though about the way the Project Managers are chosen.  Maybe we could at least start choosing Project Managers based on some minimum set of rules about their skill sets, rather than just their availability.  Or, perhaps if we got a team together in a room and then had them select their own Project Manager we might get some better teams and better leaders on our teams.

    No Comments
  • BY:  Bruce Lofland

    All tasks are being completed when planned and within budget.  There are no issues, risks have all been mitigated, and the project team members love each other and work perfectly together.  How would you like to give that status for your projects every week?  If you did, would anyone believe it?

    Real projects don’t go perfectly most of the time.  They have a few warts and sometimes are downright ugly.  Our job as Project Managers is to report the truth, whatever that is, to the world.  Getting that truth from the project team is sometimes difficult though.  What follows are some tips that will help you get to that truth.

    1. Don’t shoot the messenger – During the Operation Desert Storm (the first Gulf War), there were stories being reported by the media that Saddam Hussein would shoot his Generals if they didn’t perform well.  As a result he was often not told the truth about what was really going on.  This caused him to make a lot of bad decisions.  Verbally attacking project team members that do not tell us what we want to hear has the same effect on our projects.  If you have a customer, project sponsor, or boss that is like that you may be tempted to be less than candid in your status reporting.  Don’t go over to the dark side!
    2. Document issues – When a task does not go as planned it should be documented as an issue in an issues log.  The task could be late or over budget for a lot of different reasons.  It is important to document these in an objective way that identifies the problem and what is being done about it; but does not blame team members.   This issues log should be public to build or maintain a culture of transparency.
    3. Probe estimates – The estimates of time or cost that seem too good to be true probably are.  People are often very optimistic and do not account for risks when giving estimates.  Making mistakes and having to do rework is a daily reality in the workplace that is not always taken into account.  Reminding resources about this and asking them for more detail about the task being estimated and what they need to do it usually yields more realistic estimates.
    4. Ask for clarification until you get it – Sometimes people create confusion deliberately to hide their own failures.  This can be done with technical gibberish or just disorganized rambling.  When someone you are collecting status from does this, take the time to organize what they are saying and ask them to explain until you have enough information.  This requires some patience, but stick with it until you know the truth.  There is probably something there that you need to know

    Bruce Lofland writes his PM Technix blog at http://blog.pmtechnix.com/ .   PM Technix is a blog about practical techniques to manage projects that can be used by most project managers.  Bruce Lofland has been a Project Manager in the Kansas City area since 1999 and a certified PMP since 2007.  He was a software developer for many years before that on a wide variety of platforms.

    1 Comment
  • By: Collin Quiring

    As a Project Manager, I tend to instinctively relate most events in life back to that profession.  I have been thinking about the situation with Shirley Sherrod (Georgia’s Agriculture Department Director).  This is an ongoing story at the time of this writing and this blog is not a political or news blog so I am not writing about this from that viewpoint nor am I indicating if what is happening is right or wrong.  However, here is a very brief summary of the current situation as I understand it:  a video was posted of Ms. Sherrod talking about a situation where she discriminated against somebody she was supposed to help.  She was fired forthwith.  Now, more of that speech is being shown where Ms. Sherrod explains that she was wrong, that she corrected it, did end up helping the individual and she made a much larger point about her role in her organization and the role of race relations.

    In Project Management, we are always being asked to do more with less, do it faster, stay on top of everything and numerous other clichés meant to encourage (force?) us to act and react as quickly as humanly possible.  Well, that often means that we react to the facts as presented to us and not necessarily to all the facts or an objective view of the facts.  And, while we may be presented a set of facts with a certain “spin” from another team member, lets not forget that we have our own internal “spin” of how we are understanding those same facts.  My thoughts about getting all the information and this current situation made me think about projects I have been on where I have reacted first and then later learned more facts.  More than once I have had to go back to individuals and apologize.  And, unfortunately, a time or two the damage was already done and apologies didn’t matter (to the person or the project).

    My point is that as a Project Manager, I need to try and obtain as many of the facts before I react.  I know that isn’t always easy and there is a line between “analysis paralysis”, discovering facts and being over-reactive to a few bits of information.  One great way to discover more of a story is to ask those involved rather than assume the worst or assume the bits of information that I have are the complete story. 

    Perhaps a Risk Management plan would help with some things that occur during the course of a Project.  But, in the case when something new pops up and it “demands immediate attention” and a course of action, perhaps I need to take a deep breath, determine if I have all the information that I can reasonably be expected to obtain and then make a decision.  There are legitimate times when immediate action might be required but I think that if we react to everything like it requires an immediate reaction we may be creating extra pain for ourselves for when we learn more information.

    3 Comments
  • Clients often ask us if there is an easy-to-use and easy-to-understand method of trying to explain and justify the use of Project Management and the use of Microsoft Project.  We have some information about that on other blog entries and on some of our other webpages on our site.  However, Tanya Foster has put together a simple summary the gives a high level overview of some of the reasons to implement Project Management and to use Microsoft Project.

     This is a downloadable PowerPoint that you are free to download and use.  It can be found on our “White Papers” page (http://pmpspecialists.com/WhitePapers.html) under the heading “The Value of Project Management” and the description “This PowerPoint document is for you to use as a guide for explaining the purpose of Project Management and Microsoft Project.  As the title slide states, this is for “Making a Case for Implementing Microsoft Project, Project Server and Project Management Concepts””

     This PowerPoint presentation has the following topic headlines:

    Why Project Management?

    Why Microsoft Project?

    Is it Worth it?

    What are some Actual Numbers?

    Some of the slides have more explanation in the notes section about the topics presented on that slide.

    We think that these slides are great conversation starters and are an easy-to-use tool that might help you demonstrate some of the value of Project Management and Microsoft Project.

    1 Comment
  • 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.

    No Comments
  • 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

     

    No Comments
  • By:  Collin Quiring

    Project Management is usually involved in the creation of “the new” or the modification of “the old”.  In the beginning stages of a Project almost everybody involved talks about the great benefits, the wonderful aspects of the newer version and how they can’t wait for the change.  More often than not, however, those same people seem to throw up roadblocks to accomplishing the goals of the project as it becomes closer to fruition.

     

    Why?  There are all sorts of reasons that cause this behavior but I think that one of the key ones is the perception of gain versus loss.  When it gets down to it, people tend to like “the devil they know” instead of having to do things differently.  Besides the issues that come with something new like having to be trained in a new tool or process comes the psychological balance of risk/benefit or of gain/loss.  People tend to talk about how they want something better – newer and improved.  But, the desire to stay with the known version of what they have is extremely strong.

     

    The need for the Project Manager is to understand that just because people are excited about the gains as a result of their project they need to know what those people feel is being lost.  As Project Managers, we can become immersed in the details and tangible results of the project and forget about some of the effects to the existing situation.  As I talked about in a previous blog about marketing the concept of Project Management we need to be addressing the concerns of the stakeholders in how it affects their current (soon to be “old”) tools and methods.  This is part of the marketing and changing the perception that Project Management is only about disrupting the status quo.

     

    Project Managers must understand that the gain/loss mindset exists for every person affected by the results of the project – some of whom may not be direct stakeholders in the project itself.  We concentrate and promote the gain part of the project – which we need to do.  But, a essential piece of the project should be to try to understand and address what the gain/loss equation looks like to the people involved.  The transition of losing the “old” and gaining the “new” won’t be as difficult if there is an attempt to assuage the loss part of the equation, rather than just concentrating on the gains.

     

    No Comments
  • By: Collin Quiring

    I know in previous posts I have droned on and on about ROI.  As I have mentioned in the past, ROI is a metric and is usually a financial (aka: highly measurable) item.  But, “value” is really the important item to think about.  While ROI is important it doesn’t always measure the true value to an organization.  For example, what is the value versus ROI of the Human Resources department?  From a purely measureable statistic they are a cost center but the value they provide to the organization is significant.

     

    To that end, the Project Management Institute (PMI) has created a questionnaire that let you help determine value and priority for your organization.  PMI recently completed a massive study about the value of Project Management and then compares your answers to the results from that study to help determine what sort of assistance you might need.

     

    Take a look at it and let me know your results!  The link is under the “PMI’s Practice Guidelines Tool” on the page at this URL:  http://www.pmi12.org/

     

    No Comments