A project management information system (PMIS) is not an investment which most companies would make lightly. The one time and ongoing hard costs coupled with the change management effort involved in implementing such tools can be significant so it is reasonable to expect that there will be some tangible value derived once the dust settles.
Unfortunately, in spite of PMIS’s being commercially available for more than a couple of decades, they sometimes provide us with a live example of the Abilene paradox with everyone involved being fully aware that their system is a joy and money-leeching false deity which bestows no boons on anyone, least of all those who are required to offer information tithes to it on a weekly basis. Yet, investment in the system continues unabated, and the mandate to use it is frequently reinforced.
Does the mere existence of an implemented PMIS provide any benefit? Wouldn’t this be similar to installing a fake security camera which could provide some degree of assurance even though it is all form but no substance? Does the requirement to submit project updates regularly create the right kinds of discipline in project teams?
I highly doubt it.
Just because I am required to feed the beast on a weekly basis doesn’t mean that I will provide quality sustenance, especially if I see no WIIFM and even more so if I get coerced to do so.
What’s the root cause for such an unfortunate situation?
While we could point to a bad procurement decision, a lack of understanding of the processes being automated, or insufficient requirements gathering, these are sometimes just symptoms of the real culprit – poor stakeholder engagement.
If the PMIS purchasing decision and implementation is done without properly engaging one or more key stakeholder communities, the likelihood that data quality or presentation gaps exist will increase dramatically.
As with establishing PMOs, the implementation of a PMIS should be orchestrated like any other strategic project. It should be supported by an appropriately vetted business case, and planned and executed in a disciplined manner including effective, holistic stakeholder identification and engagement.
In other words, practice what you preach.
(Note: this article was originally written and published by me in April 2016 on my personal blog, kbondale.wordpress.com)
Something I’ve taken for granted is a project manager’s ability to create and maintain a project schedule. The reality is that most accidental project managers spend at least as much time struggling with their schedules as they do getting real value out of them.
No project scheduling tool is inherently bad, but there are a few cardinal sins that will reduce the value you achieve by using these indispensable aids.
1. Use a scheduling tool to help you define the scope for your project. Most scheduling tools are good for entry of tasks with durations and dependencies but are lousy as brainstorming or iterative definition aids. Spend the time to create a Work Breakdown Structure (WBS). Then using traditional Post-It notes or a similar visual approach, sequence the activities that will deliver the scope of your project. Once you’ve got the skeleton ready, you are ready to transition this information to a scheduling tool. Otherwise, get ready for spaghetti-like dependencies that are impossible to trace…
2. Use scheduling constraints excessively. Too often, I’ve reviewed project schedules that are saturated with constraints – these have been used as a cheap way of getting tasks to start and end on specific dates. While this may help to get a quick & dirty view of a project’s time-line, it effectively neuters a critical path methodology-based scheduling engine and eliminates the ability to optimize schedules through appropriate use of slack. Constraints should be used to capture real world situations only (e.g. we can’t start this task until the next Saturday as that happens to be the first available maintenance window).
3. Use automated resource leveling and effort-driven tasks. Automated resource leveling is a great concept but is poorly used – unless you are 100% certain about the relative priority of individual tasks (most organizations can’t even figure out the relative priority of their individual projects!), this feature can effectively shred your schedule. Effort-driven tasks work well for projects where there is a true linear relationship between resource allocation and task duration – however, on most knowledge-based projects, Brooks’ Law and the old cliché about nine women being unable to have a baby in one month come into play.
4. Capture too many (or too few) tasks. Remember that a schedule is just a model of what you expect to happen that serves the dual purpose of being a forecasting and tracking tool as well as a communication medium to team members and project stakeholders. There is equally as much pain of having a schedule that is at too high a level of detail (it is too easy to lose track of schedule progress) as there is of attempting to define and track every minuscule activity that occurs on the project (you’ll spend all your time maintaining the schedule).
5. The schedule is out of date the moment it is updated, so why bother updating it? Of course, this is a relative state, and yet many PMs seem to feel that keeping a schedule current is a waste of time. Unfortunately, this reduces the value of a schedule to purely being a task list.
6. Outline levels and milestones are GREAT! Outline levels and milestones are a good way to present schedule information in a fashion that will satisfy multiple levels of detail for status reporting. Having said that, too much of a good thing is also not a great idea – just because your scheduling tool supports hundreds of outline levels or milestones per schedule does not mean you have to push the boundaries of these limits!
7. We can’t start over… The worst sin of scheduling is to work with a schedule that has reached such a level of chaos that no one derives any value from its continued existence. Many project teams take that undesirable journey to Abilene without someone stepping back and saying “let’s start over” – not only can that reduce administrative effort but it can create the perception of a clean slate for the project team. To quote Kenny Rogers, “You got to know when to hold ’em, know when to fold ’em…”
(Note: this article was originally written and published by me in September 2009 on my personal blog, kbondale.wordpress.com)
So you want to buy a PPM or EPM (Enterprise Project Management) tool?
Congratulations – vendors will be filling up your e-mail Inbox with ROI calculators, dazzling dashboard screenshots and glowing client case studies to convince you that their solution is the only reasonable choice!
But before you finalize the business case to secure funding, let’s run through a simple list of questions. If you can’t conclusively answer “yes” to all of them and have the data to back up this confidence, it might be advisable to wait until you do.
Are your PM practices institutionalized (and how do you know)?
If you don’t have some sort of documented methodology, and don’t have the evidence reflecting compliance with those practices, why do you think introducing a tool is going to make any difference?
Do you have sustainable executive sponsorship AND resource management commitment (and how do you know)?
If you have been trying to sell these two stakeholder groups on the benefits of introducing a tool, how do you know they have sufficiently bought in? Everyone wants to have pretty portfolio health dashboards and detailed views into staff capacity and allocation, but a lot of effort on the part of mid- and senior managers is required to ensure that accurate and complete data is being entered by project teams.
Who is going to support the tool past the initial roll out (and will you have sufficient funding for these resources)?
Regardless of whether a PPM or EPM solution is installed on-site or subscribed to over the Internet, you still need to have internal staffing to provide application support to your end users, to identify and address coaching or compliance issues, and to receive feedback from end users and incorporate that feedback into ongoing improvements to your procedures & the configuration of the tool.
Beyond this, depending on your organization’s needs and the capabilities of your selected tool you may require software development assistance for creating interfaces with your other business systems and report writers to create custom reports from the tool’s centralized repository.
Will the costs of providing this support be absorbed by the tangible benefits achieved by implementing a tool? If not, how will you justify ongoing funding for it?
How are you going to “sell it” to the primary end users?
Vendors tend to target executives when selling PPM and EPM tools as dashboards and reports make for great eye candy, but to populate those dashboards and reports the burden of effort falls on project managers & team members as they are expected to enter and maintain project data.
Will you be reducing or at least not increasing the administrative work load for these folks?
Don’t get me wrong – PPM and EPM tools can provide significant benefits, but without checking that the prerequisites for successful realization of these benefits are in place you might find that all you’ve done is acquired a costly Rube Goldberg project administration machine.
(Note: this article was originally written and published by me in September 2013 on my personal blog - https://kbondale.wordpress.com)