I was recently asked for my advice about projects for someone who wants to âget intoâ project management. I told them in all honesty, that Iâd only be able to give them advice from my limited experience. Although Iâve been âdoingâ project management for over 20 years, Iâm one in a million/millions doing this. So after I shared my advice, I also encouraged my ânew to project managementâ friend to google âthings I wish I knew before I became a Project Managerâ. I hope he did. Iâm sure it would add to this list.
Here are the things I shared. Do you agree? What would you have shared?
First off, there are really only two guarantees about projects: Every project is different and Change will happen. Having said, I still have 15 pieces of advice that are pertinent to every project, regardless of size, shape, length or complexity.
- Agree the details and priorities with the Sponsor / Project Board at the beginning (not the end!)
Itâs too late at the end of the project to find out that the Sponsor / Project Board had âother ideasâ (either mentioned or not) about what the project was set to deliver. Before undertaking a project, sit with the Sponsor (physically or metaphorically â over the phone, via documentation, rounds of email or through entries into a project management system) and come to agreements about the basics for the project (who, what, why, when, how and how much) being sure to agree on time, cost and quality expectations. Most importantly agreeing which is the priority!
- Decide how to document (to whatever formal level required) and document to that level
Some small projects neednât have much documentation. A lot of information can be captured in emails and meeting minutes. But just because a formal document isnât required, understand how will this information be captured and stored. For large, complex projects, documentation is normally required. Decide on the templates, the level of detail required and the recipients / distribution lists of the information.
Once a level has been established and agreed, throughout the project abide by these documentation rules. When time pressures abound itâs easy to forget to document things. Thereâs always the intention, but it keeps getting pushed down the to do list until it eventually falls off. Be diligent. Keep records. And keep them according to the level youâve determined to be correct for your project.
You will thank me for this one when a Stakeholder comes out of the wood work halfway through your project requesting some random, yet vital piece of information that is required for the project to continue or risk losing funding/support/priority.
- Create and maintain a consistent, organised filing system for each project
Itâs not enough just to document stuff on your project, you have to file it in a consistent, organised manner. When you need to find it, fast, you can because itâs organised. Document management systems can help, so can configuration management systems. But if youâre a small project, a simple project folder structure with an Excel spreadsheet can do wonders for keeping track of project assets. Have it set up and ready to use from the beginning and use it unfailingly.
- Have a formal project kick off
Project team members are being asked to come together, work on a temporary team, do some incredible work and then disband. Itâs always a good idea to start that off on the right foot.
A good kick off meeting will give the team an opportunity to get to know each other, their roles on the project, a chance to ask questions and clarify objectives. Without the kick off, teams can meander and drift for a long period before getting to grips with the project and each other. Jump start their team development by providing a suitable kick off.
- Have a plan
First things first about plans, do not put this plan together by yourself. If you do, youâre doing it wrong. Involve others! You can put a draft together and then have others contribute, but never ever put the whole thing together on your own.
Have a plan so that you can understand the order and dependencies. Donât have a plan to use as a guarantee of the future. The second thing about plans is that nothing will go exactly according to plan. Nothing. Things will always be off. Sometimes when youâre lucky, only slightly off, but still off.
Know your tolerances or contingencies with your plans. How much leeway off the plan are you allowed before you will need to involve the Sponsor / Project Board? Document this agreement (see number 2) and file it where itâs handy to access when needed (see number 3).
- Hold regular team meetings
Thereâs nothing like a meeting. I know there are bad meetings, but at the end of the day, even a bad meeting is better than no meeting. Hearing âitâ straight from the horseâs mouth is valuable. Having everyone hear âitâ straight from the horseâs mouth is invaluable.
When everyone is caught up and understand the issues at hand, the progress being made and their place in all of it, the project runs smoother (I will never promise smoothly, but I will promise smoother). The misunderstandings of whoâs working on what and when something will be done (or not), are cleared up and people can then adjust as necessary to get work done.
- Track and manage Risks actively
Risks are uncertain events in the future, that if they should occur, will impact your project. Many team members are afraid to look stupid or foolish by raising something that hasnât even happened yet. Change that conception. Praise people for thinking of any potential event that might affect your project. More than that, reward them!
Once identified, make sure to have a consistent approach or procedure in place to actively track and manage the risk. Just having a list of risks isnât helpful. Rate each risk on how big it is (usually via probability and impact) and then decide what mitigating activities (if any) you want to put in place to deal with it. Track it through to its resolution.
- Track and manage Issues actively
Issues are events that were not planned for, have happened (or itâs known for certain that they will happen), and are impacting the project, requiring management attention. Many team members are afraid to bring up bad news to the Project Manager, not understanding that bad news early is good news to a Project Manager. The sooner the Project Manager knows about an issue, the more time there is to solve it / fix it / save it. Bad news late is normally too late to do anything about it.
Reward people for bring up the bad news, no matter how big or how small.
Ensure there is a consistent approach or procedure for tracking and managing issues. Keep a history of all issues. Even when resolved. Review often and notice patterns and trends. Treat these as risks and try to mitigate them before they happen again (see number 7).
- Track and manage Changes actively
As mentioned before, Change will happen on every project. People will change, objectives will change, the economy will change, funding streams will change, priorities will change, business structures will change â¦ the list is endless. All we know is that it will happen.
Have an approach or procedure in place to deal with changes and make sure to have a budget set aside to pay for changes. Without the procedure, changes will be included / not included on an ad-hoc, subjective manner without thorough consideration to the impact of the project. Without the Change Budget, the answer to all change requests will be NO!
Track and review all approved changes through to their completion. Track and review all rejected and deferred changes to the end of the project. Hand these over to the business, in case they choose to include them at a later time.
- Track and manage Quality Checks and Tests actively
Everything the project produces should be quality checked or tested to ensure that it meets its requirements. The tests and checks are normally built into the plan to ensure the correct time, space and resources required to do the tests are reserved. Beyond just planning for the right tests at the right time, using the right resources, these test results need to be tracked, as well. The test results that confirm the projectâs work is meeting the desired level of quality need to be monitored, followed, scrutinised and double-checked.
Itâs not enough just to have them in the plan, the end results need to be examined to ensure that not only did the test happen according to the schedule, but the test actually passed. And if there were issues with the tests that these were followed up and resolved (see number 8).
- Pause, reflect, learn often
No matter how small a project is, there will always be a need to pause, reflect and learn. No one is that good that they do all of this well. In fact, no one does. Some are good some aspects, others good at others. Build it into your plans, block time in your calendar, physically remove yourself from your office for an hour, do what you need to do to stop, take a step back, reflect. Look at whatâs gone well and what needs to improve. Go forward with this new insight and the determination to do better!
- Ensure processes are in place (and being consistently used)
If you find yourself making things up on the fly time and time again throughout your project, thatâs your first indication that you havenât defined a process somewhere. A process is a series of actions or steps taken in order to achieve a particular end. Normally that end is consistency. No matter what happens on the project, you can deal with it consistently if there are processes to follow. Processes are obviously not the end all be all of the situation, but they will help you give a dependable structure around the situation to help you manage it effectively.
Once you know your processes, follow them. Also make sure everyone else does too â there are no âcowboysâ out there doing it âtheir wayâ because they donât see the value in your process. If they really just donât like your processes, they can raise it as an issueâ¦(see number 7).
- Report upwards and outwards regularly and consistently
Youâre on top of all your project information because youâre the one managing this project. Who else needs to know? Recognise who your Stakeholders are, what information they want, how often and in what format. Deliver that communication (which is two-ways, by the way!) according to this understanding.
Reports should be consistently provided, time-wise and level-of-detail-wise. When reports are late or missing, Stakeholders will jump to the conclusion that the project is in trouble and attempting to hide it. When reports change drastically in appearance and level of detail, so that comparisons between reports is difficult or impossible, same conclusion â the project is trying to bury bad news. Stakeholders are discerning folk and donât take kindly to being lied to or misled. Consistency will circumvent this potentially disastrous and politically unpleasant situation.
- Have a formal close out of the project
Just as important as marking the beginning of the project with a kick off, it is important to mark the end with a close out. This step is not just for the Project Manager to assess and evaluate the project, but should also provide an opportunity for the team to reflect and learn from the experience.
Lessons should be identified, learned and shared. Documentation should be archived. Final reports should be distributed. And the team should be disbanded.
Although thereâs rarely any âproject budgetâ to pay for celebrations, there should still be something. Anything.
I once had a pizza party with paper-plate awards for each member of my team. It was a chance to say thank you and acknowledge everyoneâs hard work and participation. I didnât think much of it, as I had little budget and did the best I could. Years later, those paper-plate awards were still on peopleâs walls. Such a small token of appreciation went so much further than I ever thought possible!