One Version of the Truth – Culture and Microsoft Project Server

BY: Collin Quiring

When talking with customers one of the observations that I often make is something like “by using Project Server you have one version of the truth”.  By that I mean that there is a central location where you can obtain information about your Projects, Resources, specific tasks and whatever else you want to track from a centralized location.  There is ONE PLACE to get that information – and the version of that information will be the same for everybody accessing it.  If a task is late and that is causing the entire schedule for a project to be late, then all those using Project Web Access (with the right security permissions) can see that the schedule is late.

But, my statement is inferring one very important detail.  That detail is that the data in Project Server is correct, or stated differently, that it is TRUE.  While surfing the internet this morning I ran across a small post by Mark K title “What is Truth?”  In that post, he asks if “…project management software tools…reflect truth?”   (http://blog.teaminteractions.com/ep/2011/04/what-is-truth.html) I posted a quick response to his post but have decided to expand on it here.

When I tell customers that having a centralized repository of information allows for one version of the truth I am thinking about all those times when I have seen two different people come to a meeting and they both have their own report based on their own data collection system.  And, invariably, the reports do not match.  That is one of the great values of using Project Server.  The information is in one place and so the underlying data is going to be the same to start with.  And, depending on how you set up your server and reporting capabilities, there can be agreed upon template reports so that everybody has the same end report – in both data and format.  Or, reports and views can be customized so that each person has their own format and their own way to view the data – but since the data is the same then the ending values will be the same (and if they aren’t then it is relatively easy to see if somebody is modifying their data in an interesting way).

But, the reports only show what that data is on the server and it doesn’t address whether or not that data is truth. The tool can’t force people to always accurately record their information.  However, it can provide the ability to check and confirm that information once it is recorded.  For example, if I have a task that is due today and I mark it as “complete” the person that approves my update can decide to accept or reject that update.  If I have to provide some sort of document and post it when that task is complete, the system easily shows whether or not a document is posted.  There are other checks-and-balances that the Project Server can provide to us in all sorts of reports and data exports.  One client I work with has some Timesheet updates flow through to their payroll and billing systems.  This makes the incentive for both management and each individual to have truthful entries into the system.  If they aren’t truthful in Project Server, customers will notice that they are being billed for work not done.  Or, the Human Resources department will discover a payroll issue if the information in Project Server isn’t correct.

We have posted before about getting to the truth from the business perspective (http://pmpspecialists.com/Blog/2010/09/getting-the-truth/).  As that post describes, if we shoot our messengers then we are telling them to always tell us happy thoughts and to avoid anything negative.  Sometimes the truth is negative and we need to deal with it when it happens and not when the results are finally shown.  If an individual knows that their assigned task is going late, but they know that they have weeks or months before others will discover this fact and they don’t want to update anybody because they fear retribution then we have failed as an organization to demonstrate that we want the truth.

So, it is important to realize that the project management tool that we use is usually only as good as the culture we operate it in.  If we shoot the messenger then those messengers will figure out how to go around any system.  However, if we provide the right incentive to individuals to tell us the truth then our systems will reflect that as well.

It is important to note that the truth is not always negative.  On occasion, tasks are completed early or issues or risks appear that can benefit a task or a schedule.  And, sometimes individuals know that something is coming up but perhaps nobody else sees it or is thinking about it yet.  What if I know that we are going to miss a deadline due to an upcoming event that we have no control over?  For example, if I know that a critical vendor is almost assuredly going to miss a ship date 3 months from now there is a value to my organization if I bring this up as a probable risk to the project.

If the organization were to reward me for bringing this up early, rather than waiting for it to happen, I would be much more prone to bring that up as soon as I discovered it.  If bad news is met by blaming me and by “shooting” me than I will just cross my fingers and hope it doesn’t happen.  And, when it does happen, and we are suddenly forced into trying to figure out how to mitigate the problem, how much more pain and cost does that cost my organization than if I had brought it up early and we had a mitigation plan already in place?

My answer to whether or not we know that our project management tool is reflecting the truth is the “both/and” answer.  If we have a culture that expects (and both rewards and holds accountable) truth and a tool that centralizes the data then we expect it to be truthful.  And, to me one of the other benefits of having the tool is that we have an archived history so we can begin to look at information about “how long did this take last time” and we can have better and better (more truthful) schedules, expectations and timelines in the future.

Comments