In the course of my career, I’ve been fortunate enough to wear a numerous festive hats, and they have put me on all sides of the project management equation: the vendor, the client, member of the creative team, executive producer, product/ feature owner, and straight up project manager. After more than a dozen years, and probably hundreds of projects, I should have the formula for running a successful project, right?

There isn’t one. Sorry to break it to you, but after many years of managing software projects from tiny websites to large, complex multimedia projects, I’ve learned that there is no one-size-fits-all method for getting from A to Z.

The technology used for project management has evolved considerably since I first started running projects in the early 2000s. One of my early mentors came from a video production background and she carried around a huge 3-ring binder for every project. She printed out emails and meeting notes. It was cumbersome and very 20th century, but it worked for her. She had her system for scheduling and budgeting. I continued to use her Excel spreadsheet for budgeting for many years.

More recently, I’ve been learning Agile methodologies. It’s certainly the most popular system for software development, and it does work well for iterating quickly. But even the most pedantic Scrum Master will have to bend the process to fit the project sometimes.

Why is there no magic formula? Because the people who work on project teams are almost always human. People vary greatly when it comes to personality and work style, which both feed into the team dynamic. If you work with the same team on multiple projects, a status quo will start to develop. Certain tools will stick, others won’t. The frequency of meetings needed will become clear. The right process is the one that everyone on the project finds useful.

There are no hard and fast rules, but now that I’m thoroughly “seasoned” I can share a few general guidelines for successfully running a project.

1. Know who your customer is. Whether doing client work or working for internal customers, always know who has final sign-off on decisions, and lay out a clear process for getting approval.
2. Define phases with clear deliverables. A phase is not necessarily a sprint. Each phase should end with a milestone delivery and progress review.
3. Agree on deliverables before agreeing to a timeline or budget. Too many projects get spec’d prematurely, which leads to inevitable scope creep.
4. Take good meeting notes, and distribute them. This is probably the number one thing that has contributed to successful projects for me. It seems insignificant, but writing down decisions, open discussions, and next steps keeps everyone on the same page.
5. Don’t segregate your team. Designers, front-end devs, and back-end devs all need to take part in the same discussions and have input into decisions, whether they are responsible for the work or not.
6. Everyone has an opinion. Take number 5 with a big grain of salt. Gathering input from all parties is important, but a good PM is able to decide which input to act on, and which to ignore. This is where a dash of diplomacy comes in handy.
7. Scope creep is bad. Except when it isn’t. The unwritten law of the project manager is NO SCOPE CREEP, but if you’re too inflexible you may be sacrificing the overall quality of the project. The trick here is to be vigilant about managing priorities and trade-offs to try to keep scope creep, erm, in scope.
8. If it’s really out of scope, you have two choices. Don’t do it, or issue a change order. This is critical for client work, but also very important for projects with only internal customers. Stakeholders need to understand and sign off on extra work. And they need to pay for it.
9. Set a cadence for meetings. Some projects will require more discussions than others. I tend to lean toward fewer meetings, but having a regularly scheduled check-in can help keep communication flowing.
10. Centralize documentation. Maybe not in a three-ring binder. There are cloud-based solutions, Wikis, and other ways to share project docs. Choose one that your team feels comfortable with.
11. Ship it. While software is never “done” there needs to be a clear endpoint and a coherent launch plan, whether it’s a feature or a product.

Whether you use project management software or carry around a 3-ring binder, these rules will help you drive a successful project. In a future post, I’ll outline how I’ve used various project management tools and apps over the years.

Oh, and item #12: keep your sense of humor handy. Taking things too seriously will make you and everyone around you unhappy. Whatever goes wrong with your project won’t stop the world spinning on its axis.