Munich DC PM BoF Recap - 15 PM Problems & Solutions for you

Below is a recap of the discussions had at my PM BoFs in Munich this August 2012, and the resources we talked about. Thanks to everyone who came and participated!

As is the case with most of the PM BoF’s I’ve done over the past 4 Drupalcons, the conversation I was most interested in was around lessons learned. I love it when people can discuss where their projects went off the rails, why, what drives them crazy and how we can all learn from those experiences and exchange ideas/solutions.

This time we focused on Agile + Drupal in one BoF, and estimation techniques in another. I hope you learn as much from the wrap up summary as we did chatting. Many of you expressed interest in a pre-conference project management training in Portland, please contact me (shannonvettes at gmail) if you haven’t given me your information and would like to be in the loop.

PS: Please watch/review our session from Munich if you haven’t already! The Science of Guessing - Drupal estimation techniques from project managers

15 Problems & Ideas

Below are some examples of problems faced by our attendees, and solutions to help solve them suggested by the group and BoF moderators. These are in no particular order of importance, I picked the top 15 to share with you all. :)

1) Pre-sales
Problem: Not being involved in presales discussions leads to a multitude of problems on the project from inaccurate estimations to undiscovered assumptions.

Ideas: Find ways to concretely illustrate the benefits of being involved and the cons of not being involved. One way to do this is to hold a lessons learned, or simply document the previous project experiences for the sales team. Use this to convey how involving excluded parties could’ve resolved the issues faced during the project.

2) Approach != to ‘real’ agile
Problem: Not given opportunity to do "real" agile, being forced into a hybrid approach and the difficulty in managing expectations of agility with waterfall circumstances imposed.

Ideas: Ask for a test-run of doing "real" agile on a small project and measure the expected benefits of the change to prove the usefulness.

3) Fixed Budget
Problem: Given fixed budget constraint can sometimes lead to other constraints getting fixed as well as the project advances! eg: we told you from the outset that we must have x, y and z features in this project, and you’ve used up 80% of the budget -- you better make it work so we get everything!

Ideas: Focus early and often on the necessity for flexible constraints for schedule/scope/quality. Remind your client of other options to resolve their situation -- reducing scope on other fronts, adding budget, or scaling down quality to meet business value without adding so much custom work. Early buy in on this is the best/easiest way to manage scope creep with a fixed budget.

4) Role issues with Agile
Problem: Poor client expectations about their role in agile process can lead to lots of problems -- they don’t know what you’re supposed to deliver, what they’re supposed to do or the scope of the team members’ responsibilities.

Ideas: Help them understand that they need to know what they want

5) Front End Considerations
Problem: Not enough UX/UI/Overhead consideration into estimates can make them inaccurate.

Ideas: Look at past projects and try to reason what the difference of not including the time cost the team, including revisions.

6) Cutting time to save $
Problem: cutting time & cutting out quality assurances can really make the client mad because he/she might not be aware of the lengths you went to in order to deliver within his budget.

Ideas: Iteration planning that involves the client with communication that is clear about what is possible or not within the budget. Negotiating transparently instead of trying to cut down on quality assurance or time spent developing ensures that the team can do the job they need to properly.

7) The Risky Perception of Agile
Problem: “My clients think agile is risky, and they don’t want to use it.”

Ideas: It’s true that Agile is a buzzword, and not everyone understands the risks and benefits of this approach. This risky reputation might have a background -- I would try to understand the perception’s roots to determine if there was a past failure, if the client doesn’t understand the process, or if it’s a general lack of trust. Education of the client will help, but in any case, you’ll need a quick win development wise to build trust.

8) Agile Not Scalable
Problem: Agile is hard to scale for big projects with lots of stakeholders because there are so many people involved in the discussions with overlapping roles in different areas.

Ideas: If your project is getting so big that you can’t have everyone around a table for a scrum, it’s time to start thinking about building a program, and splitting the team up into product owners & project managers that can take responsibility for their expertise. A Scrum of Scrum can solve communication issues that crop up after teams are separated.

9) Who’s the key stakeholder?
Problem: Sometimes we lose sight of who the key stakeholder is on the project, and we just start focusing on delivering all the features that are being asked for which causes scope creep.

Ideas: It’s critical to success to understand from the outset which stakeholders are key to identifying business value, and what they are most afraid to lose functionality-wise. You need to know who is affected, and what the value of that affect is before you can make judgements that impact the project with your clients.

10) The “Drupal Way” is getting in my way
Problem: The client doesn’t work with Drupal, and isn’t expecting me to have preconceived notions about how things should work.

Ideas: Education is important here again. The client needs to understand that Drupal is a lego set with forms that are pre-architected in most cases and it’s a matter of putting them together in a way that makes sense. It’s a good idea to have development available for presales prototyping to cut down on risk and provide more information to the client about the OOTB functionality. Defining workflows is also an important step not to skip.

11) Scope is creeping b/c my client can’t focus
Problem: Sometimes the client loses sight of the purpose and most business critical goals; as a consequence scope grows.

Ideas: Holding a "vision session" => define the musts, what matters most to them and what is the business purpose of the project up front in order to constrain scope. You could also define metrics for success, what's their definition of "wild success", as well as several other project kick-off guidelines for determining the “why are we all here” answers necessary to guiding project scope.

12) Innovation is risky.
Problem: The client doesn't always realise that innovation is risky because of the way Drupal works. Creating something from scratch is not nearly as risk prone as adapting something that already exists due to the nature and complexity of “core”.

Ideas: The client needs to know what the value of that risky feature is before they can decide if the estimate is something they want to live with. Make them put a number on how much it means to them, and tell them how the estimate measures up to that value for investment ratio.

13) Velocity measurement with no baseline
Problem: On new projects or with new teams I’m not sure how to measure velocity

Ideas: You’ve got to develop a baseline after 2 or 3 sprints to get you started in order to have something to work off of. You can’t just invent velocity before you have data to work off of.

14) Estimations not accurate.
Problem: My estimations might not be accurate.

Ideas: You literally can not stop this from happening. The only thing you can do, is to prepare your client for its happening and try to mitigate as much as you possibly can in advance.

15) What if I’m alone in my theory?
Problem: I’m not sure others want to practice my methods, how do I convince others to use them if they don't want to?

Ideas: Instead of convincing them with a big speech, you could just ask them to give it a shot, try it out for a month and see how it goes. Alternatively, you could try to use the authority of past success to win them over with some examples. Finally, you could also try using failure of other techniques as a reason to change your team’s ways.

Resources we talked about during BoF’s and Sessions:

• How to measure anything => book about estimation
• Presentation by Shannon Vettes, Jakob Persson and Mattias Axelsson at Drupalcon Munich, [[http://munich2012.drupal.org/program/sessions/science-guessing-drupal-estimation-techniques-project-managers|The Science of Guessing - Drupal estimation techniques from project managers]]
• Presentation by Jakob Persson from Drupalcon Chicago, Getting Early Estimates Right
• Blog "10 ways to Rock Your Project Planning" by Shannon on Bluesparklabs.com
• Jakob’s Early Estimates spreadsheet
• Shannon’s Risk Matrix spreadsheet
• Link to project Behat
• Article about Test Driven Development and Automated Testing
• Planning Poker online tool
• London PM BoF recap about Drupal Estimation

Feel free to share more resources in comments & thanks for reading!