People often ask me what my top tips are for new project managers. Even those old hands with lots of practice want to know the secrets to success (not my personal success, by the way—just project success generally!).
The secret is that there aren’t any secrets.
Whether you’re running a project for the first time or the hundredth time, the best practices for getting things done in an effective manner are always the same.
Here are five project management best practices that will help you survive and deliver successful projects.
1. Be inclusive
Tech projects are rarely just about the technology. IT solutions usually facilitate something bigger, such as resolving a customer problem or streamlining a process. And the stakeholders of these projects often sit outside of the IT team. It’s your role as a project manager to work out who these people are and include them in your planning.
I’ve discovered that it’s better to include a wider group of people from the get-go. From here, it’s easier to narrow down the number of people involved, rather than trying to add people in later. When stakeholders and team members are added after the fact, they often complain that they don’t have the complete background and should have been involved earlier! Avoid the grumbles and make your initial project scoping and kick off as wide and inclusive as possible.
2. Think big
Smaller projects can lead to larger visions—so keep the door open. For example, today’s project focus might be to build an app for your local market. But you can also take this spec, and consider how you might convert your systems for other markets. In a case like this, you can build in the features to allow for a global plan as well. That’s thinking big.
Normally I’m against adding in requirements that aren’t specified by the user. However, I also think that project managers have leeway—and make themselves invaluable—when they ask intelligent questions about how this product or service can be used in the future.
Don’t build something that can’t be modified in the future unless you’re 100 percent sure that it’s never going to be used for anything else.
3. Estimate on TOTAL time
When it comes to estimating projects, it’s always best to involve the people who are doing the work in estimating the work. It’s not rocket science: these team members have probably done the work before, and they’ve definitely got a better idea of what it will take than you have.
But there’s a but (and it’s a pretty big one).
In my experience, technical people will often only estimate their part of the work. So let’s say one dev’s code change will take around four hours. Great. However, that code change then needs to be taken to the Change Board for approval, be migrated to the test environment, be tested and signed off by the users, then migrated into production—which gives us a total elapsed time of, let’s say, six days.
From a project manager’s perspective, the difference between four hours and six days on the project schedule is pretty massive.
As a project lead, it’s your responsibility to make sure that the task estimate includes everything. I always estimate on elapsed time for my high-level milestone plan because I find it easier to give stakeholders detailed information about dates when the schedule is based on total duration. You can also schedule work on an effort-driven basis if this works best for you (and it’s especially good where the team is totally dedicated to the project, and they each contribute estimates to the same PM tool). Either way, each task estimate needs to include the total amount of work from start to finish, not just the hands-on dev time.
4. Involve the users
Users are the people who have the problem that your system is trying to solve. Users are the people who have to live with the solution you build once you have gone on to design the next thing. Users matter. Involve them even more than you think you have to.
Getting users involved is actually very simple. Invite the project sponsor to nominate someone as your main day-to-day contact. Co-opt them on to the project team. Get them coming to meetings, even if at first they have no idea what the discussion is about. They should lead the work on requirements, help you with ideation, review your designs, comment on the user experience and generally be a full member of the project team.
If you have already started your project, it’s not too late. Get your nominated user to review the work you’ve done so far; to try out the prototype, and functionally test what has been built, and so on. This input will solve a lot of project management headaches as you get closer to the delivery date!
5. Be the team’s translator
Technical teams speak another language. As a project manager, part of your role is to navigate the gap between the jargon used by the IT teams and the language understood by the end-users and other stakeholders. You need to understand enough so that the techies can’t pull the wool over your eyes, and so you can explain the details to others. For example, don’t need to understand how CSS really works. Just know that it does.
Conclusion
This is my survival list for project managers. You might have other practices that you wouldn’t be without. In fact, if that’s the case, why not tell everyone about it? Leave a comment below and share your experiences with the rest of the LiquidPlanner community. We’d be happy to hear what works for you.
Whether you’re surviving or thriving, project management is hard work! (If it was easy everyone would do it, right?). Here’s a roundup of common challenges and practical tips to help you turn challenges into opportunities. Download our eBook, How to Solve the Top 9 Project Management Challenges.
