While studying for a project management certification, my instructor asked us a question that not only resonated in my head, but changed the way I would look at my role in projects for the rest of my career (or at least thus far, anyway).

“In a bacon and egg sandwich, what’s the difference between the chicken and the pig?”

As the chicken is lucky enough to tell you, there’s quite a bit of difference. This is a prime example of the difference between being involved in a project and being committed. When it comes to the success or failure of third-party projects (or any project really) in your credit union, you are the pig.

Who owns the project?

Let me preface this by saying that the events discussed here of course do not represent every scenario. We execute countless projects with excellent teams that drive success and innovation every day, so if you’re one of those, simply let this serve as a reminder of why we do things the way we do.

Throughout my career in the cuasterisk.com network, I’ve been engaged at varying levels in hundreds if not thousands of credit union projects. One situation I’ve run into fairly often that tends to leave me curious is the varying levels (a nice way of saying general lack) of commitment on the part of credit union sponsors to the success of the project. While there are many reasons that this can occur, I’ve come to the conclusion that the most common has been the perception of who’s the pig in this particular entrée.

There is a common scenario that we encounter in this business where a credit union will engage with a third party and/or our teams to perform a task for them. This could be anything: build a product, give them feedback to increase the performance of their lending portfolio, or review some area of their business or operation. We’ll often have project meetings throughout the course of the project and all seems well. We get to the end of the project when suddenly “why isn’t this up and running throughout my CU?”, “why isn’t my loan portfolio up 25%?”, or “why doesn’t the system do X?”.

There’s an (almost always undocumented) assumption that paying someone for a deliverable is always an all-inclusive package of everything you want, including installation and haul-away, like buying a fridge at the local home improvement store. That the people performing the work automatically understand your (again often undocumented) requirements or desires for a particular project or deliverable.

Identifying the pig

While there’s a high-level solution to the examples I’ve given here–don’t assume, get everything in writing–it’s important to understand why this happens. I believe the why is you don’t realize you’re the pig! There’s any easy test for this: when your boss, board, member finds out that the x dollar project or new product doesn’t perform the y function that it was supposed to, who will be sitting in the frying pan? If the answer is you, you’re the pig.

Assuming you’re the pig, you’re responsible, accountable, and in the game to run your projects and ensure success from here on out, here are some tips to help:

Communicate!

Depending on where you look, most project management resources would say you spend 90-95% of your time communicating during a project. While you may not be a full-time project manager, this can serve as an example of how truly important communication is overall. Your management team needs to know the status, costs, deadlines, and other metrics to ensure the project is performing. The project team needs to know their responsibilities, deadlines, and statuses. Your vendors need to know timelines, requirements, acceptance criteria, etc. The list goes on, and since you’re the pig, you need to make sure all sides have everything they need. There are numerous tools out there to help with each of these, but we’ll start small.

One tool we tend to use occasionally is a RACI (Responsible, Accountable, Consult, Inform) chart. While not always formatted in the traditional manner, keeping this list for your project can be extremely useful. You may do this for a particular phase, or the whole project depending on its size or complexity. The exercise generally lists out all the tasks for a project or phase, and an identifier next to who is responsible, accountable, needs to be consulted (think subject matter expert), and who needs to be kept up to date for each task. Here’s a very simple example of what that might look like:

This helps add clarity to exactly who serves what need during a project or phase. As the task is executed or completed, the team can reference this to know who needs to do what. There are other pieces that can be tied to this (stakeholder registers, communication plans, work breakdown structures), but this can get you going in the right direction.

Know what you want!

(And more importantly, make sure everyone else does too.) One of the most common things we run into as builders/developers is the unknown requirement. That business need or feature that you know the system should have, and while no one has talked about it, obviously this project will have it or it wouldn’t be worth doing. Guess what? They don’t know, and since you’re the pig, it’s in your best interests to ensure that they do. Requirement gathering is one of those situations where “there are no dumb questions.” And if there are, you should ask them anyway! There are more tools we could discuss on how to manage requirements, but the bottom line is, write it down.

If you haven’t received an answer that your deliverable will have that special feature on your mind, the only safe assumption is it won’t! Make sure you have a Requirement Baseline in some manner. In whatever form works best for your team, a Requirement Baseline is an agreed upon list of requirements that your project, phase, and/or deliverable(s) will have. In a typical formal project management environment, once this is signed by all parties, any changes to it (and by extension, the project requirements) would go through a change management process that would include documenting and approving any modifications. This helps ensure everyone that needs to be aware of changes to the project is aware, and makes sure you can get what you want. After all, at the end of the day, what happens if you don’t get what you (your CU) wants? You end up in the pan!