I've been part of many projects over the years. Some large, as in several hundred million Dollars, some smaller. Most of them has been less than successful. The latest project, however, is a resounding success. It is large, over 50 million Euro, it is relatively high tech, and it is hugely fun. It has also been an eye-opener.
Whole books have been written about project management, hundreds of them. I've read a few, but learned little. The books tend to be very general, and contains what in programming books are referred to as "patterns". I think they all have their value, but they need to be used with caution. You can not read these books and blindly apply your freshly acquired knowledge, you need to thoroughly analyze the applicability of each and every point made. (This applies to many or most books, obviously)
I think the books would be more useful if they simply contained a list of rules, which should take up a page or two, and the rest of the book should be used to elaborate on each point, and provide examples of how in practice the rule can be followed (it's a book after all, so it must by convention contain more than two pages).
So after very little deliberation, I hereby grant you unrestricted access to my accumulated knowledge of project management after a good couple of years in a well run project (and many years in less well run projects).
1. Understand the assignment
This is the single most important rule. When you were in school, I am sure the teacher before every exam told you to read the assigment carefully, and make sure you understand exactly what is required. This is fairly obvious, but I think you will find that too many projects crumble because of this alone. Make sure that not only YOU understand the requirements, but also all other members of the project team, as well as the customer. Many requirement-matrixes are blindly based on "hand-me-downs" (someone did something vaguely similar somewhere else, or someone stumbled across Google), so frequently the customer does not really know what a particular requirement means, and why it is there. This is just a fact of life, and it's better to recognize and deal with it.
If there are no requirement matrix, make one. Yes, really. Document whatever expectation the customer has before commencing the project. Then you have a baseline from which you can estimate cost and resources, and something to bargain with when the requirements change. Make the customer adopt it as his own.
Going through the requirement-matrix with the customer will ensure there's no unpleasant surprises when the project is done. Even if you've met all requirements on time and on budget, the project will still be a failure if the customer thinks he's getting something he's not.
In practice, we use an Excel workbook, with every single requirement on its own row (currently about 1200). We then go through each requirement, and try to "translate" it into something tangible (requrements are usually formulated roundly, so as to not impose restrictions on the actual solution). We then go over those "interpretations" with the customer, and ensure that we understand what the customer means by the requirement, and the customer "understands our understanding". Labour intensive for a while, but very, very useful. We also do a number of other things to those requirements, but thats the most important part. There are tools to assist in this work, but I think the mentality of ensuring you know what you are getting into is by far the most important. The tools will follow.
Almost as important as understanding the requirements is making sure the customer/PM understands your requirements. If you are to deliver a, b and c, you need x, y and z. Make sure any caveats are clearly documented. If, at a later date, these conditions are not met, you have documentation on whose responsibility this was.
As an example, I was once tasked with implementing an ERP-system in a startup GSM operator. Following my own advice, I tried to get a requirement matrix for the system. What is it supposed to do? What information do you actually want it to provide? There was no such matrix, so I arranged meetings with the stakeholders. Starting with the project owner. As it turned out, nobody really knew WHAT they wanted, and most of them didn't know WHY they should want it at all! You can imagine the success I would have had, delivering a system nobody knows what is supposed to do. I killed the project.
2. Well defined roles and responsibilities
Again something that should be self evident, but is sinned against time and time again. Every member of the team must know exactly what is expected of them, and what their authority is. It's hard to do your job if you don't know what your job is. I can not stress this enough. As I see it, it's the Project Manager's job to define and communicate these roles. If he does not do this, he is not a good PM! Simple as that.
Under the same heading I want to add "processes". Depending on the size of the project team, well defined processes are incredible important. They ensure people know what to do in certain circumstances, and also enforce #3 on this list.
3. Document it!
"It" referring to pretty much everything. If you are in a meeting, make sure minutes are taken and sent out. If it is a meeting where anything gets decided, you will have a written record of that decision. If it's a meeting where potential issues as discussed, you will have a written record of those troubles being alerted. If someone wants you to do something not previously agreed on, get it in writing. You will need it.
Making sure things are documented in this way not only serves to cover your ass, it also as a mental filter for those making the request. If they understand that things are documented and their request might come back and bite them on the behind, they will think more throroughly through their request. Which is a Good Thing.
4. Manage Change
Change will happen. There will be changes to your requirement-matrix, or schedule, or something else. Make sure these changes are documented, and that you clearly communicate any and all effects of that change. If you are in a project for a paying customer, having a clear requirement-matrix (as you of course will have after reading Rule 1), you can now recuperate any additional cost associated with implementing that change. If you do not have a requirement-matrix when the project starts, you are working blind. The cost estimates for the project was based on air, and it's hard to charge extra (or ask for more resources) for more air.
5. Interfaces
In any project you will have interfaces to other systems/parts of the organisation/something. It could be technical interfaces (protocol x/y/z), or it could be organizational (so-and-so are your responsibilities when operating this and that). Make sure those interfaces are documented.
Translation: make sure you have a document which clearly states what you will deliver, and what you need the other party to deliver, with a timeline. Make sure it is signed by both parties. Partially to cover your ass if the other part does not deliver on time, and partially to force the other part to recognize the interface.
6. Take responsibility - Establish trust in the group
If you are a Project Manager, or in any other position where you get to take decisions, take them. Remember, a bad decision is infinately better than no decision at all. And you need to take those decisions, even if you don't like nor care for them. That's the price you pay for playing the Big Man.
This is also paramount when it comes to establishing trust in the project group. If the people who work with you do not trust you or each other, they will never pull in the same direction as you. Which is a sure-fire way of cocking up a project. Projects are difficult enough when everybody is on the same page and pulling in the same direction, let alone having to deal with individual agendas.
If you are not in a position to make decision, you still need to earn the trust of your managers. Easy enough; deliver quality work, on time. Thats all there is to it.
7. Don't assume
Anything. Make sure "someone" reads through any and all documentation sent from, or used by, the project group. Any solution or process should be approved by a key member of the project team. If you have sub-contractors, make sure you have someone in the team with enough knowledge of the subject to ask the tricky questions, and understand if something fishy is going on. Yes, I have seen BIG projects fail because the project team assumed the sub-contractor had the best possible technical resources to do the job, and it was not really worth it to kick up a shit-storm to get resources on the project team who could do QA on the design-documents. (Turns out, there were no design-documents. The big, multinational tech-company was winging it. And failing.)
8. Get commitment
I've seen too many project staffed by 5% resources. "This guy will use 5% of his time, that guy will use 10%, together with all the others that will make up the total number of hours required". I've never seen it work.
I think it boils down to ownership: If I only have a marginal role in a project, I am unlikely to look really hard for potential problems, and take action to avoid it. Someone else must have done that already. But when ALL the resources are marginal, none will. I've turned down several projects because they only wanted a few percent of my time. It has nothing to do with money, I get paid the same either way, and all to do with success. I don't want to be part of a project I do not think will succeed. So, when you staff your project, make sure your key members are 100% allocated (or damn close). If you are a key member, insist that you are 100% allocated. If this is not possible, I would walk away.
9. Risk Management
Risk Management is one of those terms which are kinda hard to pin down, as it could be pretty much anything. I like to think of it this way; EVERYTHING we do in the project is rooted in risk management. Everything that is documented is documented in order to minimize the risk that we're not in control. Any product chosen is chosen in order to minimize the risk of it not doing whatever it needs to do properly. Any technical solution or routine is establised to minimize risks. The Excel-sheet in Rule #1 is used to minimize the risk that we miss our target. Having a concious view of risk management is important, as well as useful.
In practice, we do risk management sessions at various times in the project. For any big change, we assess the risks associated, and come up with ways to mitigate the risks. Then we make sure the risks identified is communicated to the "higher ups". Again, the mentality is the important thing. How you choose to implement it is up to you.
10. Test
After anything has been implemented (not only technical solutions), make sure you test it! Every testable requirement should be tested and documented, but also functionality that has not specifically been requested. I've never seen a requirement matrix that specifies that the users must be able to change the passwords on their PC, but it's a pretty big deal if it doesn't work..
This is also one of the things we go through when we discuss the requirements with the customer. At the end of the project, time comes to get paid. If it's a sizeable project, the customer wants to make sure you've delivered everything you've agreed to. Asking the question for every requirement "how should we document delivery of this requirement" is worthwhile. Once you can produce test-reports for the requirements, objections tend to go away. Which is another Good Thing.
There are more..
There's a lot more rules, but those are Top 10 in my book. I will mention one more, but without a number (or else it would be "Top 11 in my book", which doesn't really work..) A Plan. Really? A plan? Yes. A plan. Every project has a plan. But they are frequently badly formed, and not really followed. The plan should contain all your milestones, the most important tasks, and whatever interdependencies there are. That does not mean it should be as detailed as possible, but rather that the "right" tasks should be there. And it should be followed up. Every week the team should assemble and report the status of their tasks. If something is falling behind, the plan will show any snowball-effect, and solutions or new priorities should be implemented in the plan. The plan is not a static document, but rather a tool for managing the progress or lack thereof.
In general this last statement applies to many traditional tools in PM. They are not something you just need to have because the book says so, they are tools, and need to be used as such. If something really does not help with finishing the project, just drop it. Find something else that works.
A lot of what I have written can be interpreted as "Cover Your Ass" tactics. It's not. When everything is documented, uncertainty and risk is minimized. Everybody knows who is responsible. How often have you been in a situation where the opposite party says "Me? I thought you were supposed to do that?" Having it documented (and accessible) will aid in minimizing silly misunderstandings like that.
I do not suggest you let something slide because you know it's not your job. Quite the opposite, actually, make whoever is responsible aware that something is not up to snuff. This is perhaps the most important rule of all; have an environment in the project team, and include the customer in this, where everyone is looking out for each other! Making mistakes is not a hanging offence! (Making the same mistake twice is, however)
