by Donald Kennedy

For those who have been following my roller coaster career, I am currently working in the planning group on another of my $100 Million projects at an oil sands facility at approximately the same latitude as Juneau, Alaska but 1000 miles west.

This is a follow up of a post from January 2024. In that post, I offered three actions that the people who manage project managers can take to help steward the resources under their control towards more optimal outcomes. I see that I presented a paper on a similar topic at the 2010 ASEM annual conference in Rogers, Arkansas. The content is based on years of experience looking at successful projects (and of course unsuccessful ones) and noting how the managers above the project manager influenced the outcomes. As well, I have 14 more years of observations to help support my points. For more on the first three recommended actions, see the January blog post.

Action 1: Learn how to best manage technical people.

Action 2: Give the project manager the maximum amount of trust and authority within your organization.

Action 3: Trust the project managers.

Action 4: Allow the project manager to focus on looking forward.

Action 5: If you really need to know something about completed events wait until the execution phase is over

One thing that really frustrates me in the middle of a time sensitive project is having to explain variances of the plan versus progress to date. The budget might say there are 2 trenches required but 4 were dug. Why is that? I tell people below me that there will be plenty of time to look at such things at the end of the project and there are numerous things that need to get completed now in a very limited time. Do these answers really need to be provided now? Sometimes an executive will tell me that it needs to get done now because if we wait there will not be budget left over to pay people to work on such follow-ups. My answer is always that if there is not enough budget to explicitly pay for such information, it is not considered a high enough priority to be worth doing at all. I have almost never seen any analysis of variances used successfully to help future projects anyway.

On a recent project that was $60M in size, the manager above me wanted me to analyze the budget breakdown to better match where the costs were reported versus where they were originally planned to be slotted. I called this work “slicing the pie to see if it changes in size.” On this project the manager in question was fired mid project, partly due to enough people above him seeing this was not adding any value and truly was directing focus away from future planning. Things went a lot smoother when the request for budget transfers evaporated. At the beginning of projects and data first comes along, there might be requests for explanations that are very immaterial in the grand scheme but seem important when there is little going on. I recall one manager wanting to know why someone was on site that was wearing a hard hat that was obviously not theirs. I said to wait 2 weeks when there will be 200 people in hard hats on site and see if you still take the time to check who is wearing which one.

Action 6: Allow access to unaltered facts and information.

At one organization in the early 1990s, they were at the beginning of moving from paper to digital systems. When setting up their equivalent to what would now be called an ERP system, the computer people asked my manager what access I should get. My manager was aware enough to recognize the advantages of knowing things and the answer was “why not give Don full access?” And they did. Ten years later, I would get requests from project managers looking for historical information on past projects that were perhaps executed by a different department that they are not allowed access to under protocols developed after I started. The effort required to justify granting access to people deemed not requiring it was much greater than just asking me. Companies are very protective generally about their proprietary information, but I often say that if they are worried about the value of the information, just think what their own employees could do with it if they had access!

Action 7: Don’t rob the project team to staff other tasks on the go.

I worked at many places where project managers are assigned projects to execute but they are not given any dedicated team members to help them. People will then be regularly assigned to other initiatives with the thought that perhaps “multi-tasking” will magically allow greater productivity by having one person do tasks that would normally require two or more. Anyone who has been in this situation must realize that having many tasks on the go often assures that they all end up being late. In some very large projects, I witnessed great success by utilizing outsourced resources but only when these resources were pulled out of their parent company and physically placed in the project office and dedicated to that project. I also know that large EPC firms are very reluctant to allow their employees to go work in other locations because they find it is often very difficult to retain them after the seconded people get their foot in the door of a much better work environment. This speaks volumes about the current macro environment where a firm has to restrict exposure of their employees to other organizations due to the fear of losing them. If you want to explore this tangent more, I wrote many articles on the evils of the current high employee turnover being experienced everywhere. But to achieve optimal performance on projects, which is the topic at hand, installing dedicated staff focused on the project is an action that helps the project managers execute their work.

Action 8: Don’t confuse the team by having them wonder to whom they are supposed to listen.

This action is totally within the control of the people who manage project managers. To increase the chance of success for project managers, they need to be assured their directions are being followed. I was on one $100M project where the project manager made the effort to get the team to understand that it was much better to get some things early than to risk any critical items coming in late. The financing cost of buying everything a few months early was approximately $300,000. However the cost of delays in execution were approximately $100,000 a day. The liquidated damages owed to the client for every day the project completed past the deadline were $50,000/day. In the end, the project finished a month late ($1.5 million in damages). The estimate for the overruns due to having people standing by while waiting for one critical part was $3 million. In a post project analysis, it was eventually discovered that the VP Finance was pushing the procurement group to delay purchases to save on the financing costs (interest on the money spent buying things early). Since the buyers reported to the VP finance and not the project manager (reported up the line to VP Engineering), the buyers followed the direction of the people who controlled their raises and employment. I experienced many examples of similar frustration where I follow up on a particular action to discover that my request was subsequently overruled by a manager not concerned with the project I was executing.

Conclusion

I hope you found these recommended actions of interest and useful. Change is unlikely to come from the ground level up. The implementation of these actions lies in the hands of the people directing the project managers and hopefully not also directing the people the project managers believe are dedicated to supporting them.

About the Author

Dr. Donald Kennedy, Ph.D., P.Eng., IntPE, CPEM, FASEM is a long time contributor to the Practice Periodical and ASEM blog.

BLOG DISCLAIMER: The opinions, views and content presented in this online blog solely represent the original creator and has no association with ASEM activities, products or services. The content is made available to the community for educational and informational purposes only. All blog posts are created voluntarily and are not sold, but may be used, shared and distributed free of charge. The blogs are not academic pieces, and therefore do not go through a peer-review process, and are not fact-checked. All errors belong to the creators.