When it comes to project planning, and reporting project status, how would you gauge your organization on its participants willingness to tell the truth and report what is really happening?
Many years ago I was interviewing for a job, and the person conducting the interview went out of his way to impress on me that their organization had a culture of telling the truth. I was puzzled by that at the time, not because I didn’t understand what it meant to tell the truth, but in retrospect it was because I was most fortunate during most of the formative years of my career to have worked in organizations where telling the truth was the norm. I came up in an environment where you were encouraged and to tell the truth about the status of your project deliverables, no matter how unpleasant it may sound. You were also encouraged to call out someone else’s BS in status meetings. This fostered a “culture of telling the truth” in project management and reporting. I didn’t know any other way.
Since that time, for many years I have been working “out in the world” as a consultant in IT organizations, and I have found out what the “culture of truth” guy was talking about. He was reacting to a condition that many organizations have, which is a culture of denial and BS when it comes to reporting project status. This is why so many IT development projects run off the rails and come in late and over budget. Whether you are running your project as Agile, Kanban, waterfall, or something else, you inevitably have to get to a place in the project where you have to face the cold hard facts about what is working and what did not turn out as planned. The sooner you get to those conversations, the better the overall project team can react and make course corrections. This is why telling the truth early and often is better for the overall project success, and why avoiding it can inevitably lead to disaster.
How can you do your part to promote a culture of telling the truth in your organization? Whether your role is an engineer, architect, project leader, product owner, scrum master, quality assurance, you all have a responsibility to foster a culture of telling the truth. You may feel that you don’t have enough influence on the organization to affect change, but every bit counts. The short answer is this: be the example you want to see in others. Here is a list of guidelines:
- When asked about estimates and you don’t feel that you have enough requirements, say so. At the same time, don’t be so black and white that you create analysis paralysis. There are always grey areas, and at some point you have to punt with what you know and go with a SWAG (simple wild-ass guess). Make sure you don’t start your estimating with a swag. It has to be grounded in something. Put the time in to investigate what you can about a certain subject but eventually you sometimes need to go with an educated SWAG (e-SWAG ? :))
- If you feel the entire estimating process is not grounded in reality, you must speak up and say so. There are more details on how to deal with the tension between guessing and holding your ground on requiring facts when doing estimating, which we will get to in future blog posts.
- If you have a deliverable that is taking longer than expected, then don’t be afraid to say so. Be clear about what you think is causing the slippage. Examples include:
- Unclear requirements
- Dependencies on other teams deliverables that aren’t being met.
- You underestimated the effort.
- Admitting that you underestimated the effort is the hardest to do. But engineering leaders know that this happens all the time. Try admitting it and you may find that your scrum master or dev lead will appreciate your honesty and will want to work more closely with you take compensating action.
- When things are going wrong, be proactive about offering solutions. You are working every day at the intersection between the requirements and the solution. You are in the best position to offer up alternative approaches that the technical leadership team had not thought of.
- Pick your battles carefully, and be constructive. You don’t want to be the person who is constantly warning that the sky is falling, but you do want to develop a reputation for being the one who calls out that something will take longer than everyone is saying, or calling out that a work estimate is pulled completely from thin air. As long as you have some constructive talking points about why, people will listen to you. Ultimately you and your teammates are responsible for the deliverable so its better to be brutally honest up front than make excuses later.
- Don’t be afraid to call people out when you see they are not being fully honest about something. Yes, you need to work with these people on a day to day basis, and nobody likes a snitch, but you need to think about the success of the project; honesty is the best policy. If you’re calling out something that is failing then you’re only saying what others are already thinking. Be a role model for the truth, and people will respect you for it in the end.
- If you are in a leadership role, responsible for gathering data to formulate an assessment of project status, don’t be afraid to ask the hard questions. Ask detailed questions that make people uncomfortable. Make them tell you how and why everything is rosy. Watch their body language. You can tell a lot from that. A daily standup meeting is the perfect venue for this, as it is much harder for someone to BS you and all the rest of team when there are peers in the room that are depending on the work being delivered, and those peers probably already have an idea that a deliverable they are depending on is suspect.
Sometimes a culture of BS originates from higher up the management chain, above the level that you feel you can have an influence over. To be fair, people in those positions have a constant battle between overseeing the development project, and reporting to the business people how the project is going. The people on the business side most likely don’t understand the nuances of software development, and all the things that can trip you up along the way. The senior technical leadership may have experienced situations where the business have pulled the plug on a project because the truthful status report indicated that it was going to cost more and take more time than initially projected. This leaves the senior technical leadership wanting to “spin” the story of what is really happening rather than lead with the blatant truth. Leave the spinning to upper management to them, but make sure you voice your opinion to the technical leadership.
Lastly – A word of caution: Use your discretion. Calling somebody out for not telling the truth is perfectly fine for a daily standup among your peers, but is not appropriate for a town hall meeting where your CTO is giving a status update to the whole company 🙂 You should still have the conversation with that person, but do it in private.