Asking a question is an art, and I recently made an artistic fail.
As a consultant, you ask a lot of questions: What are the pain points? What is the current state of affairs? And my all-time favorite, how long will it take to accomplish such task? Questions are supposed to give you answers, and yet, something about the way I asked my question did not yield the answers I needed. It took me at least 24 hours of rapidly proceeding through denial, anger, grief and acceptance (I’m pretty sure I skipped the bargaining stage) to start to figure out where was the fail.
While providing project management, scrum master and business analysis services for a particular project, I asked the development team lead to provide me with an estimate to complete a specific portion of the application software project. He answered at a face-to-face meeting on Monday. However, by Thursday of the same week, a new development manager posed a similar question and the answer and estimate were 400% higher. As the development manager was discussing the “new” estimates with me, I was gobsmacked! How did that happen in just four days?
You often hear that situations gone wrong are the best learning opportunities. I wholeheartedly agree, but it is still a terrible feeling. It’s embarrassing and something that you would prefer not to repeat. It was time for me to figure out what lessons this “Golden Opportunity” had provided. After analyzing the situation and debriefing with team members, I was able to derive three key lessons learned.
Lesson #1: When one resource is providing multiple services (i.e. wearing many hats) on a project, it is imperative they balance the competing priorities that could create conflicts of interest.
The resource providing scrum master services acts as coach and ensures the team is continuously evolving in the agile methodology. The resource providing project management services is the keeper of the timeline and budget and needs to critically evaluate whether the current situation presents potential issues or risks to the timeline and/or budget. The resource providing business analysis services helps to uncover the project business requirements and is responsible for encouraging the team to add as much functionality as possible. If the business problem is challenging and you are committed to solving it, there is a tendency to encourage optimism and over-commitment.
Lesson #2: Estimates are notoriously understated because of the optimism bias.
As a lecturer who teaches project management, I have discussed this bias with my students ad nauseam, which makes re-learning this lesson even more painful. We are all guilty of failing to see the many possible things that could go wrong during a project. And for those risks we do identify, we believe we are less likely to experience them than is true. This conundrum was reinforced as I continued to read and research all that goes into software development estimation. Studies have shown software estimates to be, on average, 40% underestimated[1]. So, unless the estimators in question have already learned that valuable lesson or perhaps never needed to learn it, you might want to consider multiplying that estimate by 140%.
Lesson #3: An estimate can be biased by the process.
The last contributing factor to the underestimated piece of work is the way I led the estimating conversation. The work for our team was divided into two-week increments, “sprints” in scrum language. When I asked for the estimate, I embedded the pieces of work inside the sprint schedules. The resource providing the estimate was anchored on a two-week time frame, to which I confirmed my expectation that the work could be completed in such time. Anchoring is influencing the frame of reference for the estimate, thereby biasing based on that frame.
Requesting an estimate is often a qualitative and subjective process that can be translated into a number often perceived to have a level of precision that it may not possess. That does not mean you cannot do it more effectively. My role in this project was to set up the conversation in a way that gave the team the best opportunity to ensure as accurate an estimate as possible. I will approach it differently next time and feel reassured that there are effective tactics in place that could better set up the team.
These three lessons learned do not make a master artist. However, making a commitment to improving one’s self by learning from past mistakes puts you on the road to powerful improvement.
I look forward to the journey.
[1] Software Estimation: Demystifying the Black Art