For all my recent writings about project management and associated tools, project management is ultimately about interacting with people. The best tools and methodologies won’t work if the project leader is not comfortable dealing with the human side of managing development.
I recently moderated a round table discussion with a group of entrepreneurs, where founders posed questions about issues they have run into while trying to manage development work in an early stage startup. In some cases, the founders are technical gurus managing a team of developers for the first time. In order cases, the founder has a business background and is not intimately familiar with development practices. Both groups of founders end up running into similar issues that highlight the need to demystify how developers work and think.
Here are some of the questions posed, and the answers that we came up with as a group. I do hope that these FAQ’s can help others navigate the same waters. Good luck!
What do I need to know to create a realistic project plan if the work is outside my area of expertise?
- Always make the project plan in collaboration with the people who will be doing the work
- Ask probing questions to understand the risks. Is there technical risk? Is there product definition risk? Is there a risk for workscope creep?
- Take the time and care to understand the approaches and estimates presented by developers, and make sure assumptions are aligned. Sometimes they aren’t – and there is a better and faster way just under the surface, if you ask good questions.
- Consult people who have done similar types of projects for a sanity check: “Are we crazy?”
How can we get better work estimates? My developers are constantly off by a factor of 2 or more.
- This is normal! No one can anticipate everything, and work estimtes are asking them to do that. This is why most people estimate too little time to get work done.
- The only way to improve is to measure and learn. Ask the person doing the work to offer an estimate. Then measure the actual time elapsed, and start building up data. You will be able to back out the “fudge factor” for each person.
- Now you can do two things: you can apply the fudge factor to future estimates, and you can also share this with the person and ask them to help move the fudge factor closer to 1 over time.
I have a business-driven deadline that cannot be moved and I need a deliverable by that date. My developers say it cannot be done. How do I proceed?
- First of all, back off on your personal definition of the deliverable. You may have assumptions that may overconstrain the solution without realizing it. It’s time to get creative in changing the deliverable to fit the date.
- Gather a cross functional team together with the objective of figuring out what can be done by the externally imposed date – be sure to include people who can think about the problem and the many ways it can be defined, and people who can come up with solutions for each variant of the problem statement.
- Now moderate a series of discussions where you challenge the team to look at the problem and define it in new ways. Most of the time, you can come up with an alternative definition of the problem that is aggressive but feasible.
I am constantly surprised by missed deadlines. How do I fix this?
- To head this off, never wait until the deadline to check on the deadline. Frequent check-in’s are key – how are they doing? Are they stuck? How can you help them succeed?
- Daily scrums are also a great way to prevent expectation mismatch – if things are slipping you will catch them early.
- If this keeps happening, you should sit down with the developers and discuss what is going on. Are the deadlines unrealistic? Are the goals not clearly articulated? Is there misunderstanding about the work scope? Find the root cause of the slippage, then collaboratively find a way to address the issue.
How do I know if a developer isn’t goofing off if I’m not watching them all the time?
- If that is how you feel, why did you bring that person on board?
- You should vigorously screen for culture fit when interviewing candidates. This should not be a problem if you bring on the right people.
- That said, sometimes people become disengaged over time if they are not feeling tightly engaged. Engage them by sharing the broader business context so they always know how their own work ties in to the big picture.
How can you get developers to do more faster?
- DO share business context and engage developers in dialog about the state of the business and its complex needs – the more the developers feel they own the problem, the more creative they will become in looking for alternative ways to solve the problem that will get to the end goal faster
- DON’T order people to work longer / work more, especially if you aren’t working longer with them. Work smarter – in a group.
- Be aggressive, but be realistic – don’t believe in magic when it comes to resource allocation. If it doesn’t fit, find another way either by cutting scope (best) or extending time (less good), never by telling the team to do more faster without being constructive with suggestions on how to morph the work to fit the available time.
My developers don’t like the tools I chose for managing development. How do I bring them around?
- Unfortunately, this is the one place where compliance is a condition of employment. Gently tell the developers that while you hear their concerns, you have chosen the tools and they need to be used (and share why).
- If there is excessive pushback, you may be running into a confusion of roles and responsibilities – the developer may be laboring under the belief that they have equal say in every decision. You will need to have a difficult conversation with the developer to help them understand they need to agree to disagree, and move on. You may need to revisit your on-boarding practices to make sure this will not happen with future team members.
How can I get things done when everyone is a part-time contractor?
- Prioritize, prioritize, prioritize – figure out what the main thing is for each person, and help each person manage against their priorities
- In some cases you will need dedicated resources – you will need to clear their plates of other work to make room
How do I balance the prioritization between features and bugs when doing demos?
- As long as it is just demos, prioritize bug fixes solely around the demo path – other bugs may need to wait
- If the demo is to be left behind to be used by users not working on the project, then when the features are at MVP level, bugs must be taken care of.
The sub-teams aren’t talking or coordinating. How do we deal with silo thinking?
- At a small scale this should not be happening – there is probably some team dynamic thing going on. The team leads may not know each other well enough or they may be operating from different assumptions – it is up to you to help them develop the trust and confidence that will move the team towards increased effectiveness.
- The best way to do this is to go one-on-one with the leader of each sub-team to hear their concerns – make it safe for them to share their thoughts, and figure out the root cause of this behavior.
- Once you have a good handle on the personal dynamics and some ideas on how to proceed, you can bring them all together in a moderated discussion to discuss concerns and come up with solutions to improve communications and coordination.
- You may have to instigate a “scrum of scrums” – a regular gathering of the sub-team leaders – to kill two birds with one stone: accelerate coordination, and accelerate relationship building.
How do I manage remote employees effectively?
- See my post on managing geographically distributed teams.
What are good meeting cadences?
- See my suggestions for meeting cadences in this post.
Are there books I can read about product development processes?
- For software teams practicing Agile, I recommend “Agile Excellence for Product Managers: A Guide to Creating Winning Products with Agile Development Teams” by Greg Cohen. Unlike most other Agile writings, which are very development-centric, this book takes a holistic view of how four separate constituencies (product managers, UX designers, developers, software quality assurance engineers) must work together to build a great software product.
- For hardware teams developing a mass produced product, try my free e-book: “Bringing a hardware product to market: Navigating the Wild Ride from Concept to Mass Production”. Also available on Amazon.
- For teams developing a medical device, check out the Appendix section of the paper “Mapping the Medical Device Development Process” by Scott Ham of California Polytechnic University.