I realized recently that I’ve been leading product development projects for more than a quarter century now, with a bunch more years of product design experience on top of that.
Over this time, I’ve collected a list of project management tips that seem more and more valid to me as time goes by.
My experience has mostly focused on developing iterations of prototype medical devices and other products. Consider this context in the following suggestions.
Have Fun
I believe a project team is most effective when they are having fun. To some this might sound frivolous but don’t underestimate how productive a team can be when they are really enjoying their work. They will be more likely to gel and more likely to deliver those really great ideas. When I introduce a project to a new team member, I try to kindle a spark of interest and curiosity, among all the other mundane details. I figure that team members who are allocated to multiple projects will tend to focus their energy on the fun ones. I have noticed – for instance – that I really start getting traction on a project when I’m jazzed about it. I assume this is true for others too!
Nurturing this culture in the first place, and then not mistakenly killing it, is often a challenge.
Visualize Done
I find that I am constantly trying to figure out what done looks like, both to determine what my team is really trying to accomplish, and what the project sponsor really needs. This often is an iterative process, first to get in the right ballpark, and then to refine it.
For whatever reason, our budget is usually determined before we have a very clear idea of what done looks like. That makes it pretty important to hone and socialize the details quickly to ensure we’re all working efficiently in the right direction. This can be a bit freaky for people new to this strategy, but somehow it seems to mostly work out.
A big opportunity for project success is often available by late changes in the definition of done. For this reason, I am always speculating about new definitions, both with the team and the project sponsor. There may very well be a big win in there somewhere, waiting to be discovered: finishing faster, reducing risk, hitting budget, achieving better performance.
Trust Your Team
I suspect we’ve all worked on projects where the PM is pressured into choices that make the team’s job really challenging. Typically, what happens in these circumstances is that a few team members will voice concerns. Initially these concerns are gut-feelings – difficult to substantiate. As the situation gets tougher, the whole team becomes disillusioned and the joy evaporates.
I believe it’s the PM’s job to listen when the team voices concerns and notice when their optimism takes a hit. Even without sufficient evidence, the PM has to treat it seriously and push back for the team. If the team doesn’t feel the PM has their back, then once again, the joy suffers.
Don’t Whip Your Team
I see this behavior so often. Someone is late on a task and the PM calls them out, usually in a team huddle. Unfortunately I’ve been on both ends of this numerous times, and I’ve learned that it never helps. The only outcome I’ve noticed is that a team member now feels like crap.
This is really tricky as a PM; you need to figure out how to get the project back on track, yet it’s so easy to instill the thought that this person is underperforming and letting the team down. Similarly, the rest of the team sees the whole thing play out and that makes them worry.
I’d appreciate any tips on how to work through this sort of issue. My approach is to engage with the individual and focus on their design approach, and particularly what done looks like for that task. If the task is really running long on time or budget, I evaluate whether there’s a significant architectural change possible that will reset things. Engaging the broader group can be helpful but this also can be tricky, ensuring that everyone is thinking positively about potential solutions, and avoiding anything that could be interpreted (or misinterpreted) as blame.
Don’t Over-focus on the Gantt
A trick I have learned about Gantt charts is to only make them as detailed as the key project milestones. Digging further down into all of the time interdependence of individual tasks is a thankless job which doesn’t create much value.
Mostly there are key high-level tasks and milestones that should be tracked in a schedule, like when a prototype design is complete, when parts are ordered, when a first prototype build is ready for testing, or when prototypes are complete.
I find that the only reason to explore tasks with increased granularity is to track the project burn-down. This is effectively achieved with a list, with each item assigned the estimated effort. As tasks are completed, it frees up that effort, and the total estimate to completion ticks down. The burn-down of the high level tasks can inform how we’re tracking to the big milestones that everyone cares about.
A related approach I use is to only break tasks into subtasks when we’re closer to doing that work. The only reason to subdivide tasks is to improve the granularity of our burn-down and to act as a reminder to not forget particular things. Often, it’s better to wait until the work is right in front of us before we get lost in the details.
Schedule Always Loses
It’s pretty common for people to talk about the PM triple constraints (budget, scope, and schedule) and which one is most important in a project.
No matter what anyone says, budget seems to always win. When the money runs out, the gears stop turning. A project where money truly is of no concern pretty much never happens.
If budget is king, then scope follows a close second. Yes, there is often flexibility in how good a prototype needs to be, but there is always a minimum level of doneness required. If you haven’t achieved it yet, then you’re not done. And don’t just work to the minimum here, that’s never a good strategy!
So, if our budget is constrained and mostly immovable and there is a level of done that must be achieved, then the schedule must come last.
I’ve worked on many projects that tried to force a schedule and they always turn sour. The problem is that if you’re not done, you’re not done. Constantly focusing on being late drives all sorts of unproductive behavior: poor design decisions, reduced morale and increased mistakes. Poof goes the joy in the project.
I’m not saying here that all projects will be late – only that in my experience when things get tricky, schedule always draws the short straw.
Estimate with Data
If you’re estimating a project, a top down approach based on historical data works best. A bottom up approach looks impressive, and conveys a veneer of accuracy, but often is bloated and difficult to review for accuracy. Instead, using actual performance data points for similar projects – ideally for your particular team – gives a more reliable effort estimate.
In my mind, the purpose of estimating is to establish the bucket of cash that you will need to complete a project, not much else. Later, you will want to set yourself up for monitoring and controlling the project progress. That requires a different sort of project decomposition and analysis and often is well suited to a bottom-up approach.
Of course, it can be helpful to do both – you will need to eventually. Then you can meet in the middle and build confidence in your numbers.
The key is to use historical data whenever possible. That way you’re starting with numbers that have been proven. The next step is to figure out how to repeat those results in the new project.
Small Teams
The only thing a big team is good for – in my experience – is burning budget really fast. If you want your team to go faster and your team members are not working full-time on your project, the best thing to do is to get more of their time, not get more people. If you can’t get more of their time, you may be better off just going slower. The alternative is burning more budget through lack of efficiency.
Yes, you need people with all the required expertise. The more you can consolidate that expertise into a small number of cross-functional individuals the better. I’d say it’s still better even if they are not super-experts in some of those areas.
Look for Wow
It’s pretty common that during a project, you or one of your teammates will come up with an idea that sounds really great. It might be taking the design goals a little bit farther, it may be a new twist or opportunity that will make the project go more smoothly.
In that situation, I always give it some consideration. I first ask whether we can achieve this new idea within the budget and time available. Often – especially early in the project – such ideas come for free. If the new idea falls within the design mandate then I’d say go for it. If it’s beyond the mandate then plan to discuss it with the project sponsor. If there is project risk associated with it – there almost always is – then still give it strong consideration. Think through ways to mitigate that risk. Think through the severity to the project if the risk comes true. Perhaps consider designing in a Plan B or setting up a de-risking experiment.
If the idea pops up later in the project, still consider it. After some thought, it may not force a total rip-up, or maybe it can be implemented in a limited way. Maybe it really is so revolutionary that it’s worth a total restart.
Keeping your eye out for these opportunities and trying your best to foster them is a great way to boost team spirits as well as impress clients.
Finding a way to just get it done is best, within the existing budget and mandate. Turning every opportunity like this into a renegotiation of scope and budget tends to kill joy.
It’s Never Too Late to Ditch a Bad Idea
Similar to jumping on good ideas when they are discovered, I find it’s also the right choice to jump on bad ones as soon as they are identified. An example might be when a previous architectural choice is discovered to be wrong. When found early, it’s no big deal. Sometimes though, they pop up later in a project and that makes things difficult. Nevertheless, these problems will continue to get worse. Before you know it, it’s a full-on Hail Mary with layers of band-aids and it becomes harder and harder to correct.
We are constantly having to make architectural choices with limited information. Some of these turn out to be great – others not so much. Once we recognize that we’re not heading for greatness, then we should quickly correct. If this means a bit of a project reset, then let everyone know that needs to and correct the course. Hoping things will somehow get better when you know they’re on the wrong track is not a great strategy for success.
Don’t Make Decisions Too Soon
It’s often comforting to make decisive architectural choices early in a project. It feels like we’re really honing our trajectory and we feel that the increased clarity in scope will increase our chances of success. In my experience, putting off decisions until they are absolutely necessary can be better.
Not all decisions need to happen right away for a team to be effective. Some decisions will naturally become better informed as other tasks move ahead. Those are the sorts of choices that are worth holding back on.
We can still make note of our options, to the resolution available, but hold off on choosing definitively until we really must. I don’t mean delaying the project; I mean not making a decision until you are at the point where you must proceed down one fork or another. As you approach the fork, you can be thinking through the information that you really want to have when you get there. This might lead you to change the order some tasks to generate this collateral; maybe there are some new activities that will help with the decision.
The problem is that once a decision is behind us, we start compounding decisions on top of it. Before too long, the ability to undo it becomes way too costly.
Efficient Teams are often Resource Constrained
I find that when a team is running at maximum efficiency, it is always a little resource constrained. This is presumably an outcome of some of my other rules of thumb: keeping the team small, budget and scope come first, etc.
The trick here is to get used to it. Yes, your project will bottleneck from time to time. Yes, tasks will slip if others over-run. I would think very carefully before you consider pulling in another team member, especially if you only need a fraction of their time.
I hope you’ve found some useful nuggets in these tips. Maybe some of them resonated with your experiences, maybe some suggest a different and possibly useful spin on managing prototype iterations.
Image: StarFish Medical
Kenneth MacCallum, PEng, is a Principal Engineering Physicist at StarFish Medical. He works on Medical Device Innovation for a variety of areas including ultrasound applications. Kenneth would enjoy hearing from readers about their reference designs and experiences.
