Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.
Easier said than done!
It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.
A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.
Although Gantt charts have been around since the early 1900's, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn't also provide some incremental benefits.
This need could arise from any of the following causes:
The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success.
If there is a need to have an overall integrated project schedule, the agile teams' sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.
With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.
It can be a significant step towards improving project management capabilities when a company decides to move from storing project information in an inconsistent fashion across multiple files, databases and templates to capturing this information within a consolidated project management information system (PMIS).
By taking this step, they position themselves to reap multiple benefits including reducing the effort involved in reporting project status at the portfolio level, providing a consolidated view into staff utilization and available capacity, and simplifying the process of accessing historical project information to serve the needs of future projects.
However, as with the implementation of any new technology, behavior changes is required to achieve these benefits.
If there is no change in the quality, accuracy, timeliness or completeness of the data being captured, the outcome is actually worse than if no solution had been implemented. While the lack of easy access to project information in the past would have prompted concerned executives to seek out project managers to get live updates on project status, once a significant amount of effort and cost has been spent in implementing a PMIS, they will want to see some return on that investment and will be likely to use it as the official source of project knowledge. If the data within the PMIS is not complete or accurate, there will either be a loss of credibility in the tool or even worse, poor decisions might be made based on bad data.
So what are some tell-tale signs that your PMIS is ailing?
So what might be the cause of some of these symptoms?
Sometimes, it might be that executives and key stakeholders have never used the PMIS as their source of project information or staff utilization. If that is the case, then it’s no surprise that project managers or team members may be unwilling to invest the time to keep the PMIS up to date.
Other times, it might be a training or coaching issue – if no one is regularly keeping an eye on the data and following up on compliance or quality issues it’s no surprise that it will get stale.
Another cause might be that the system or procedures are too onerous or time consuming to use – this points to the lack of an effective feedback loop with end users which could have resulted in fine-tuning or improvements to the system.
The source of most of these issues is a lack of good change management practices.
A PMIS can improve the productivity of your project teams, but remember that a pile of garbage in a colorful bag with a decorative bow is still just as smelly!
(Note: this article was originally written and published by me in July 2013 on my personal blog, kbondale.wordpress.com)
For many, the Holy Grail of PM tools are those that are able to automate all aspects of the project portfolio management life cycle. There is something very appealing about being able to guide PMs, sponsors, stakeholders & team members through a methodology by removing any opportunities for inconsistent usage. The assumption is that presented with a single path, everyone will dutifully follow that path resulting in higher quality decision support data for executives.
There are a few challenges with this Utopian scenario:
A better approach might be a coach/mentor expert system – for example, the tool could suggest an appropriate decomposition level for the WBS, or could notify the PM if the risk register is getting stale. It is still left to the PM to decide whether or not to accept the advice, but such a system coupled with a feedback loop (e.g. “was this advice helpful?”) could change the role of the automation from Big Brother to Bagger Vance.
(Note: This article was originally written and published by me in June 2011 on my personal blog, kbondale.wordpress.com)
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)