I remember sitting in a professor’s office – surrounded by textbooks, the thick smell of old paper and older carpet – during my graduate student days. We were talking about the work it required to publish scholarly articles and how the quality of an academic paper changes with the knowledge and experience that a scholar gains over time. The professor noted, “If I try to read some of the things I wrote 20 years ago, I get a little embarrassed at what I was able to get away with then, compared with the rigor I have to use now.” Even with the many post-mortem analyses I’ve performed over the years, I have never had a heavier dose of that perspective than while studying for my Project Management Professional (PMP) Exam.
The PMP is arguably one of the more difficult professional credentials that one can try to attain. It requires at least two years of experience working on projects, as well as some study before taking an exam that (IMHO) is designed to trip you up. While a Consultant doesn’t necessarily need this credential to be successful, for me, it made all the difference in advancing my knowledge and expertise in tackling challenging projects.
In the interest of post-mortems and informed hindsight, I thought it would be insightful to revisit some previous projects to explore PMP concepts in action. In other words, let’s revisit some of my long-gone experiences as a less-seasoned consultant to see how experience and a PMP credential informs a Consultant’s approach.
PMP Concepts #1: Scope Creep
Get all your project needs sorted before starting.
I once had a Client that needed us to create an Access database to do some banking reconciliations more efficiently. The Client had a lot on their plate, and they needed someone to come in and provide much-needed computational relief.
They were toggling back and forth between a report provided to them from their banking institution and their own internal data. The task was to pull in the data from both reports and to create some queries that would make it easier to recognize variances so that the reconciliation would happen more quickly. To start, I was given some general guidelines as to how the final product should look.
[First day on the project]
CLIENT: Would you make sure to have fields A through D calculate the variances?
JUNIOR CONSULTANT: Of course! I’ll get right on it for you.
[A few weeks later]
CLIENT: No, this doesn’t look right. I needed fields E and F. Otherwise, I can’t do a proper analysis.
JUNIOR CONSULTANT: Of course, I’ll add that to the list and provide you with an update shortly. Hey, by the way, are there any other fields that you need? Here’s the list of what I have…
CLIENT: No. If you add in those pieces I mentioned, we should be good.
[A few days pass]
JUNIOR CONSULTANT: Here it is! I’ve added those two additional fields.
CLIENT: I see what you’ve done here, and that’s fine. But I can’t do the analysis without fields G, H and I. Also, can you calculate J?
JUNIOR CONSULTANT: Of course! The customer is always right after all. Let me try to add these additional details in.
And this is how it went for a few months, with the Client continuing to change their mind on what they wanted with the Access database. This might have happened because they were busy and not fully able to communicate their needs. But in the meantime, the final product became a warped version of what was supposed to be a clean design.
Looking back, this is a classic example of scope creep, where the requirements for a successful project grow outside of the originally determined scope, budget or timeline. At the beginning, the Client only wanted four fields to be able to complete their analysis, but the project requirements ballooned to ten fields and even more afterward.
Had I determined the scope beforehand, and had the Client commit to that scope, the interaction would have gone more like this:
[First day on the project]
CLIENT: Would you make sure to have fields A through D calculate the variances?
SENIOR CONSULTANT: Yes, I’d be happy to do so. I want to make sure that all fields that you need are present in order to complete this project on time and within your budget.
CLIENT: Yes, that’s all I need.
SENIOR CONSULTANT: To ensure the project is a success, I will send you an email with a mockup of the output of the Access database prior to building it. You can verify whether that is what you need.
Two things are happening here. First, I would be determining the scope of the project prior to building anything. It’s a lot faster to design a database correctly from the start rather than bolting on additions later. Second, I’m preventing scope creep by having the Client sign off on the original scope. Once the Client is faced with agreeing to a written verification of scope, it will hopefully cause them to realize that they need to think their needs fully through.
Related Posts
PMP Concepts #2: Accountability
If you need to rely on others, first make sure they are reliable.
I took on another project where I inherited a Client’s accruals process, which required the help of a dedicated person on the account receivables team to complete different sections of the exercise. Later, I found out that the process was done incorrectly, as the previous person wasn’t receiving the help that they needed from the accounting department.
PREVIOUS PERSON: Do these steps and then reach out to Steve from the A/R department for this piece of the puzzle. He’s very busy, but if he can’t help you, then you can reduce the A/R by the amounts that are older than X amount of days. These will probably be flagged as bad debt expense anyway.
JUNIOR CONSULTANT: Okay. I can try to reach out to Steve earlier, so that he has it on his radar that I will need his help eventually on this process. I would rather have this process done correctly than guess.
[After sending emails with no response a week before the due date, then three days before, then day of, JUNIOR CONSULTANT decides to go to STEVE’S desk.]
JUNIOR CONSULTANT: Hi Steve, can I get the information I need from you to complete the accruals process?
STEVE: Oh yeah, I don’t do that anymore. That’s gone to Sally.
JUNIOR CONSULTANT: Okay, thank you for letting me know. [To SALLY] Hi Sally, Steve mentioned you’re now the point of contact for the accruals process?
SALLY: Yes, but I’m swamped with other things. Can I get it to you in a few days?
JUNIOR CONSULTANT: I needed to get this done by today. I’ll send what I have for now, but next month, I’d like to have a more accurate report prepared.
In this case, I did exactly as I was instructed, but I was not able to complete the report as accurately as I could have, even though I had sent multiple emails. As it turned out, I had been ignored by Sally as well over the next few months. Eventually, I flagged the issue to the Controller, who then helped me complete these reports himself after discovering how swamped his team was.
In more complex projects, a common practice is to use a RACI Matrix (i.e., Responsible, Accountable, Consulted, and Informed Matrix) where everyone working on a project has an established role to play via a formal project document. As a Senior Consultant, the process would have been to verify who was responsible for the task by reaching out to a VP of Accounting or Controller at the beginning when the problems first arose.
PMP Concepts #3: Stakeholder Engagement
For interdisciplinary projects, you’ll have a better outcome if the disciplines are actually talking to each other.
Another situation occurred after I received my PMP. However, by the time I entered the project, it was already late into the process. I was working for a Client that was trying to create a new revenue stream. Creating the new stream required an interdepartmental approach that included resources from finance, IT and the product departments. The departments were relatively siloed, and if I were more junior, the interaction would have likely gone like this:
JUNIOR CONSULTANT [to each DEPARTMENT separately]: What are your expectations for ongoing costs this month? And what are your expectations for the costs related to the new revenue stream?
FINANCE DEPARTMENT HEAD: We’ve got some preliminary figures based on what was in the first draft of the budget, so we can just use those for now.
IT DEPARTMENT HEAD: I can tell you about ongoing costs, but I don’t know with the new product. We’re knee deep into a new software implementation, and I need to focus on that.
PRODUCT DEPARTMENT HEAD: We’ve got an outline of what we want to do, but it’s going to need some dedicated Consultants who are professionals at getting a product like this off the ground. I’m concerned that we’re going to go over our existing budget with this new product line because our current expectations are way higher than when we first drafted it.
A more Junior Consultant would have let sleeping dogs lie. I would have been following my mandate by simply reporting last month’s costs for each department and calling out variances when and where they occurred without looking at how all the pieces worked together.
However, a more Senior Consultant would need to create a stakeholder engagement plan, a work-based structure and a financial management plan from the beginning, once it was decided to go forward with creating a new revenue stream. A stakeholder engagement plan usually contains information like what percentage of a person’s time can be dedicated to a project (e.g., 50% of a finance manager’s time, 10% of the IT department head, 80% from the product director). The low engagement from the IT department head would have prompted a work-based structure discussion where an internal or external hire would facilitate the project from an IT perspective to ensure success.
From a financial management plan perspective, that would mean that we would have an allocated budget for a capital project, dividing the dollars by the required labor from each department. This would have allayed any concern from the Product Department for going over their budget simply from executing the new project. Unfortunately, I entered the project right as the budgetary process was concluding and was not aware of the misalignment between departments. My only recourse at the time was to flag the issue to the CFO and to try to set up a meeting between the different departments to address it.
Related Posts
PMP Concepts #4: Communication
Even if a project is ill-planned, have a feedback loop to check how you’re doing so you can get yourself back on track.
Another encounter I had was with a retail organization that was continuously in flux and as a result had a lot of churn in their workforce. In one instance, there was a lot of pressure to implement a new store management tool that would assist in assigning labor hours in a given month based on the latest forecast. The driving force behind getting better control of labor hours was that the executive team wanted to see a 15% reduction of labor costs in the next year. Since the Client was more of a top-down or hierarchical organization, the expectation was that when the new tool was distributed, that store managers would be expected to immediately implement it. The interaction went like this:
CLIENT: We need a tool that will display all the individual stores’ total allocated hours based on the budgeted dollars. We need it to have a dropdown menu, so that you can select the store. But we also need each region to have their own tool so that they can’t see other region’s allocated budget, since that’s sensitive information. The budgeted hours also need to be broken down by day and by week as a guidance given their historical sales numbers.
JUNIOR CONSULTANT: Ok, it’s a little complex, but I will try to get all of that in the model.
[After a few weeks]
JUNIOR CONSULTANT: Here is a draft of the model, please have the operations team take a look and provide feedback.
CLIENT [to OPERATIONS TEAM]: Please see the draft. If it works, send it out to the store managers.
OPERATIONS TEAM: No changes needed. We sent it to the store managers.
[A few days later, several store managers send back complaints about the model]
CLIENT: Hey, your tool is broken. This field was supposed to calculate X, but it doesn’t. By the way, while you’re making updates, please add these two other fields and make the calculation different. Last time, we said to calculate X, but what we really need is Y.
JUNIOR CONSULTANT: I’ll look into the calculation error, but it’s as you had requested. I can set up a meeting to show you what I mean and to go over what you need for those two other fields.
CLIENT: I don’t have time. I need to run to another meeting. Just make sure that it’s right the next time you send it.
After sending off the tool without having had proper testing prior to implementation, the process went through a lot of iterations and corresponding drama. In the end, the management found out that store managers weren’t using the tool at all because they were more comfortable using what they had used before. It wasn’t until after a few months that the store managers had admitted to this.
The roll-out occurred eventually, albeit a bit clumsily. However, best practices in project management would suggest having done the following for a smoother, more efficient transition:
- A statement of the problem (i.e., high labor hours) and the solution (i.e., labor hours tool) with an outcome expectation (i.e., reduce labor hours by 15% compared to last year)
- A well-defined scope of what is needed for the labor hours tool, or perhaps a descriptive Statement of Work/mock-up design
- A realistic timeline for the rollout
- A list of the key players (i.e., stakeholders) responsible for implementing the solution, which would have included store managers for executing and the operations and finance teams for planning and control management
- A clear responsibility matrix to determine who needed to do what during the implementation of the labor hours tool
- A risk management plan, or a risk register, to determine how we would respond to failures/errors that cropped up
- And, most importantly, a communications plan to determine how different players would communicate to each other
I titled this section as an example of how communication could have been better. Unfortunately for the labor tool rollout, there was little communication between the store managers and the corporate office on what they needed to meet the 15% labor reduction goal. There was also poor communication in terms of what the operations team needed in the tool. There also should have been, at the very least, a well-thought-out mockup design of what was needed. Instead, the design part occurred over a few hurried meetings because of the internal pressure at the Client to address other priorities.
Getting a list of staff members in a RACI Matrix with their respective availability would have at least highlighted the problem of being understaffed. This would have then prompted a decision point of either staffing up to get the project done or to delay until existing staff became available.
Conclusion
I know that I’m more likely to make better decisions ex post facto and that rehashing these old projects is at best a mental exercise. It’s difficult for my perfectionist tendencies to accept the fact that less-than-ideally-completed projects are a learning experience, but I wouldn’t be who I am personally or professionally without having stumbled a bit. I’d like to point out that even though I’m writing from the perspective of a Senior Consultant with a PMP, that not every project requires that credential to be successful. I’ve learned a lot from experienced managers who took on multi-phase, multi-million-dollar projects successfully, without those three letters after their surname. Experience with project work, using best practices and avoiding worst pitfalls, is what matters the most.
For the readers of this article who are Consultants themselves: Take “the customer is always right” or “follow the leader” advice with a grain of salt. We’re all human and can make project mistakes no matter how experienced we are. It’s okay to speak up with alternative approaches; your end goal is to help.
For the readers that are considering hiring a Consultant for some project work: a lot of these errors could have been avoided with someone experienced in project work. It’s better not to wait until a project goes sideways to bring someone in. 8020 Consulting has a variety of finance and accounting Consultants on board that have years of experience spanning different industries. We are happy to provide our services to fit your project needs, no matter what phase or development stage it is in. If you’d like to learn more about our project management capabilities or get support from 8020 Consulting, visit our financial project execution page, or contact us directly. You can also learn more about our services by clicking the image below:
