BLUF: Always present realistic expectations.
One of the biggest issues that I always see with software projects is timing. Either from developer inexperience or misunderstanding of the problem, but there always seems to be a example of over promise and under deliver. We all know this to be the opposite of what you should follow. Always under promise and over deliver, but don’t do it so much that people expect you to be super conservative with your estimates. It is your job to estimate a project timeline and what tasks can be accomplished in the time given.
You need to have regular meetings with your stakeholders to keep them informed. If something happens to the project that needs to be addressed before the next meeting so that your team can move forward, then gather information, inform the stakeholders, and make a decision. Recently we had to make a decision to refactor our front end code base from Knockout.js to AngularJS 4. We had a deadline looming in 4 weeks, but in order to move forward and not waste more time with Knockout.js development we needed to have an extended runway. I quickly asked the boss for an extra 4 weeks to make this happen now and feel like we weren’t running in place. After laying everything out we got our extra 4 weeks.
That boss was the CEO. I had to tell him that we weren’t behind, but that this would a great benefit to us in the long run. Obviously I can’t and don’t get a lot of face time with the CEO, but I needed to go straight to him and let him know what we wanted to do, so that he could make the business decision.
We still have to maintain all expectations. My team is rebuilding the flagship product and we receive requests all the time from the “good idea fairy (GIF)”. These are the sales and marketing teams that start off with “You know what we could do….” or “What would be great is…” These are the beginnings of an extended project timeline. A customer has not even seen our product yet. We have to be able to say a resounding “No”. Not a “We’ll see” or a “Maybe” knowing we will never get to it.
I am not the most experienced developer, so estimating getting something done is not always the easiest task and sometimes I have to overcome inexperience in estimations with extra time to make sure I get done what I said I would. I have to stand by what I said or have a really damn good reason as to why I did not make my deadline. We don’t build mission critical systems, so I am lenient on myself with 100% code coverage and every feature working flawlessly, and I definitely fall in the camp of putting documentation off until last.
Things happen and events occur. You cannot prepare for everything, but you need to be able to communicate how something is effecting your project, so being well informed all the time enables you to provide better expectations to stakeholders.