Project Management Basics
First off, let me say that project management is often misunderstood by many people as some complex art only to be done by specifically certified professionals. I am an engineer with over 25 years of Automation and Control Systems work and in that time, I have been lucky to have had few exceptional project managers. I have also seen so-called certified and qualified PM professionals completely mess up projects.
I am neither certified, qualified nor claiming to be a great PM, I am merely trying to pass on some of what I have learned from practical experience working with some great PMs.
Second, basic project management works just the same for small projects as it does for super huge multi-billion dollar projects. The last job I had was a simple drafting job for a security company - it was the least technical work I had done for a decade and a nice bit of relief. The job before that was a $4 billion mining project for one of the largest mining companies in the world. My key responsibility was to sign over around $300 million of machinery from the construction crew to the commissioning crew - high stress and high pressure. It also had some of the best and worst of project management I have ever seen.
These two projects were so different they should not have had a single thing in common but they did.
At the security company, the manager had put a "Lessons Learned" summary from previous projects on the notice board - it read as if it was written for the mining project and could have applied to many others. It made me realize a fundamental truth - project management at its core doesn't care about money, complexity or industry; it is simply about "how we get a job done".
I am still reasonably new to Freelancer but am seeing some of the basic mistakes I have seen in the past. So my intent here is to pass on some of what the good PMs have taught me.
This isn't about Gantt charts and risk assessments and PM theory, it's about practical understanding of key concepts as I have been taught.
Knowledge is Power
I know it's cliché but in PM it is also a fact. If you know you can plan, if you know you can manage, if you know you can help - then it's that simple; otherwise, you should always ask.
Part of why I am writing this is to let people know that they should not be afraid to offer a small project and get help starting and specifying it. If you’re not clear about what you want, you can’t expect to get the person you need. It shouldn't cost much and every $1 of advice might save you $100s in pain and grief.
And one other bit of knowledge advice - Freelancer has a simple and effective NDA (non-disclosure agreement) system. USE IT - IT'S YOUR IDEA, PROTECT IT. I intend on submitting another article on NDAs and why I would want to have it as a contractor.
It's a Team
Unless a project is yours alone, it will usually involve at least 2 people. It doesn't matter if it's 2, 20, 200 or 2000 it's still a team and team thinking is what top PMs do.
In particular, there is no such thing as "your problem" because in any project, every problem is in reality, "our problem". Bad PMs dump problems onto people, often isolating them. Good PMs hand them to people in a way that says "I trust you with this and I am here to help when you need it". Call it whatever form of group or team psychology you like, good PMs do it well.
If you are not communicating, nothing else really matters. Either you will not understand what you need to do or the other party will not understand what you want or what you are doing.
If you are managing people, you will lose track of what they are doing or what progress they are making. The best PMs I have worked with are all simply great communicators.
In some of the recent mega projects in Australia, there have been disputes with legal settlements over $1,000,000,000, and that doesn't include the ones with only 8 zeros or 7 zeros or 6 zeros. How much do think would have been saved with the right question at the right time with the right answer?
Assumptions hurt Projects
That last mining project mentioned above had a great but unfortunate example of this. Freelancer projects can have milestones. A key milestone in big engineering projects are what we call FATs - Factory Acceptance Tests (or Testing).
On that mining project, some of the FATs weren't really FATs but simply inspections by a junior engineer. The problem was others assumed that the equipment had been fully tested, but it wasn't.
To cut a long story short, it ended up causing some serious issues with lots of aggravation and some ugly accusations. My manager did the smart thing and listened. He then followed that by passing on accurate information to his manager and got a new procedure approved. My task was writing that procedure and I would love to say I saved the day but in fact, all I did was listen to people who made me aware of things, not make assumptions and pass on critical information as needed.
Had we done as some had assumed we would have been in breach of the main contract; worse, we would have missed some very serious and very dangerous faults in the equipment delivered.
At milestones, you simply cannot make assumptions; otherwise, things get missed and eventually the project suffers for it.
That's what I meant earlier when I said I saw the worst and best of project management on the same project. The worst was people assuming things not based on facts. The best came from people who simply listen.
Time is the most valuable commodity in any project
Despite Doc Emmett Brown, Marty McFly and the rest of Hollywood, it is impossible to go back in time and fix things.
Of all the worst assumptions made in any endeavour, is the false belief that we can make up for lost time -- which you can't. All you can do is make the most out of the time you have left.
Not keeping track of time or not estimating how long things will take is the most common cause of project grief. Some things have to follow after others and if one is late everything following after that is late. Eventually, someone or some task is left with no time. It's easy to understand and yet it happens on big projects as easily as it does on small ones.
Gantt charts and project diagrams are wonderful except they have one major trap, people adjust the task times to make the picture work. Gantt charts are great for identifying what resources you need and when you need them. If you need more resources, go and get them. Assuming some part of a project can be done in less time than you know it should take isn't logical and it cause trouble every time.
Your best chance of getting paid (big project or little project), is to prove it works and you need to give yourself time to do that. Planning how you do that is the most important time task you will ever plan because it's the task that gets you paid.
Assessing and Understanding Tasks
Understanding the overall task and the individual tasks at the same time is a fundamentally hard concept. Simply because the individual tasks can have many solutions while the overall task has few. Say, mining for example - we are going to dig x-tons/year out of that hole and send y-tons to that ship so it can disappear over the horizon. And it really is that simple when they plan a mine. But then how you dig that dirt up, process it, stockpile it and then get it onto that ship is any number of solutions.
If any of you go and look at any Freelancer project it’s not any different. There is the overall scope that is usually quite simple and can be said in 1 sentence. The details are generally a lot more than 1 sentence.
Fundamentally, most people can assess tasks they have experience with, it's not a big secret. But most never stop to think how you process that in a wider concept. In my case, I saw something in 2005 that let me formulate a method to follow.
What I am about to describe is the method that works for me. All the good PMs do similar things in their own ways. This works for me and if you find a way that works for you, use it. Because it doesn't matter what PM tools you use if you can't assess tasks effectively, it won't matter.
In 2005, I was watching a documentary on the Iraq War and part of it was comparing it to the First Gulf War (1991) and why it was over so quick yet this time there was no end in sight. It discussed what was done after the Vietnam War to not repeat what happened there - this is exactly what engineers call "lessons learned". A retired US General Jo Hoar gave a brief description of the main points of the "Powell Doctrine", which is simply a series of questions (check Wikipedia and the documentary was by PBS called "Rumsfeld's War").
Even though they were talking military planning and strategy, the way it was explained made perfect sense in my engineer brain. In engineering terms, those main points are specifications, resources, technical viability and closeout. The way I paraphrase it is, "We are all in agreement about what we are going to do, who is doing what, how we are doing it and when we will be done".
I simply ask are these things clear for the project and each task in the project. Before anyone says that's too simple have you ever heard any of the following?:
"you haven't done what we asked", "we need more time", "we need more people", "we need that tool", "that was never going to do the job", or "you said 1 day a week ago".
For those who are interested, I do have examples of these things but I am trying to keep this article in a reasonable length.
In particular, it helps identify "critical path items". These are things that everything else depends on. Getting them wrong kills projects.
1 Specifications - We are all in agreement about what we are going to do
Specifications are simply what "WE" agree will be done. Some specifications are simple most are "Shrek's onion" simple on the outside with layers underneath. Beyond everything else, it's most important everyone agrees on them because the worst thing you will ever hear on a project is a phrase like "I said this was a bad idea". If there is a voice of dissent, listen to it.
My rules on specifications are:
1: What's in the specification is not a problem, what's missing is.
2: That item that's not important always is.
3: There is no such thing as too much detail so long as it's relevant and doesn't cloud anything.
4: Vague specifications mislead; usually straight into chaos.
5: Changing the specification is fine so long as everyone agrees on it and everyone is duly informed of the change.
Some of the worst things you will ever hear in a project meeting are:
"we thought we could do......." (as in rule 1)
"we thought this would be better......" (as in rule 2)
"where did it say......" (as in rule 3)
"but we thought that meant........." (as in rule 4)
"when did that change......." (as in rule 5)
If specifications are concise and clear, following them is a simple means to success.
2 - Resources - who is doing what
Most people immediately think resource means people but it's more than that. First it's skills and making sure you understand which ones you need. There is no use having a room full of engineers, lawyers and doctors when you need a plumber.
This is something Freelancer is really super for - accessing skills.
Secondly, resources includes money - sorry but it does. Top PMs are smart at spending and understand what things actually cost. The true cost of any item is a combination of the cost to buy, deliver, include in the design, install, check, test, commission and maintain. Sometimes a more expensive item may save enough time that it's actually cheaper.
Thirdly, Tools and Equipment is another resource and one sadly misunderstood. There is no use having the wrong tool or not having the right one. No matter how great your spanner is, it is useless when you need a screw driver. An expensive tool may save so much time -- it’s worth the cost (rent or buy) even if you only use it once. If tools need calibration, make sure it's the right type and make sure copies of certificates end up where they are supposed to be.
3 Technical Viability - how we are doing it
This is one of the least understood parts of PM. This is the one things you must get on top of early. Hope never gets a project done and it’s rough when you get deep into a project and you realize it will not work.
Simply put a viable solution: one that you have reasons based on facts or experiences that says it is going to work.
When you break down the items in a project, three basic types exist: known knowns, known unknowns, and unknown unknowns. The first word refers to some part of a project the second to its solution.
Unknown unknowns are what every project starts with. Until you write it down, it's unknown and without a solution, it is an unknown unknown. If you write it down, it's known but until it has a solution written down, it is a known unknown. And written down means they are literally written down - itemas that are not listed will get you. How many times in a meeting have you heard "....forgot that...."?
To change as many known unknowns into known knowns, I use standard (sometimes brute force) solutions also called COTS (commercial of the shelf). Don't waste time on easy to solve problems while the project has other problems that you do need to solve.
Never underestimate or dismiss other people's experience. All it takes is that one piece of information to be the difference between success and failure.
Again, Freelancer is super for finding that one person who knows that one thing you need. As I said at the start, every $1 of advice can save you $100s in pain and grief.
Most importantly, never shelve known unknowns or you will leave them short on time or worse, short on both time and money.
Unknown unknowns can also be those things that suddenly appear in a project. If you are not prepared, you are in serious trouble. The only defense is to plan time to deal with the unexpected. It might not make much sense to expect the unexpected, but you need to be ready for something not to work as you expect.
In engineering, we identify tasks and reduce the unknowns by doing a FEED study (Front End Engineering Design). It’s basically a formal process of identifying tasks and giving each some basic information and requirements. In big projects, this can be a simple list of the main sections or components with some details and requirements. That can be then be followed by a secondary FEED studies on each of those parts. Basically, a FEED study is the start of the process in working out what needs to be done.
Even on the simplest projects, you need to do a task list. For starters, it provides you with a check list for the end of the project. How many times have you gotten well into a project and forgotten to do something?
Doesn't matter if you do a detailed FEED study or a simple task list - you can't have a viable solution to anything you don't know about.
4 Closeout - when we will be done
This is by far the worst thing engineers do in projects and it wasn't until I worked under a couple of first class PMs that I got a handle on this.
Going back to the documentary I saw, this was the one point General Hoar emphasised and probably what really caught my attention. Simply - "If you don't define what it means to be done you never will be done". Ask yourself, have you ever been on a project that felt like it was never going to end? How many times have you heard "can you just do this for me?"
The simplest form of this is a checklist. In big projects, it's simply a lot of checklists, test sheets, performance reports, inspection reports, etc.
Most importantly you should always define and agree as early as possible, it means that the job is finished. If a client will not do this, you can expect trouble - without a defined list, they can always say you’re not yet finished. Equally, if a contractor will not agree, they can drag out the hours and cost the project out of existence.
In big projects (especially oil & gas), there are 2 lists that get defined right at the start. The first is the SDRS - Supplier Data Requirements Specifications (or Schedule) and it defines types of things that you are expected to deliver - things like drawing headers, test sheets, report formats, etc. The second is the SDRL - Supplier Data Requirements List and it’s usually a table that lists all the documents you are to supply. Basically, it's a big checklist.
One thing you must expect, no matter how simple or how complex a closeout is, is never ever leave anything out or fake anything - you will get caught. It happens more often than you think. I know because I have caught people trying to not do the right thing several times.
Simply agree with the other party what it means the project is complete. If you’re the client, it spells out exactly what you want and gives you the best chance of getting what you’re paying for. If you’re the Freelancer, it gives you a check list and the best chance to get paid.
Project management isn't some mystical process done by wizards and it never was. When I saw that documentary, it simply made me realise that the reason why the good project managers made it look easy was because they weren't making it complex. They did the simple things like being organised and did them well.
One of the best PMs I ever worked with didn't use fancy PM software or Gantt charts he simply used an Excel Spreadsheet; just a very simple process and it worked super well because he was organised. We knew what we were doing and where we were at and what we needed to do next.
The first class PMs I have worked with:
- simply knew what we all needed to do
- simply knew our progress, what we needed to keep going and what we would need ahead of time
- simply worked out if what we're doing was going to work
- totally grasped what we needed to close the job out
I do hope this helps any and all who read it. If you have any questions, I'm here on Freelancer. If you don't want me for anything then do look through the Freelancers as there are some very well credentialed people there.