Let’s first start with this:
We love you! Developers adore our project managers .. FOR REAL! 💜💜 There is nothing better than working with someone who has proven structure and timelines, allowing for Dev troubleshooting, education, and mistakes to be made in their timeline.
Here’s the issue .... please, for the love of all that’s holy 🙏🏻 .... don’t take an idea and run with it before involving developers. I promise we need to give you actual timelines based on the work to be completed before any delivery dates are discussed with stakeholders. Promising a hard and fast delivery date before vetting the work with the actual developers will always come back to bite you in the a$$.
Let me repeat
Do not promise stakeholders a hard and fast delivery date before vetting the projected work with the actual developers that will do the work.
This is the single biggest issue I have been tripped up by, over and over and over again. I understand there is excitement for this project! We are excited too! Trust me, developers LOVE a shiny, new challenge to get mad at and love for a few months or even years. We looooovvvveeee it!! 😍💜😍
However, when we hear this new idea that only has an idea and initial bulletpoints, no wire frames, no user input, no research ... and then we hear “and we need to deliver this cool idea in 6 months”. That’s a problem. The Project Management Triangle Quality scale has just been trashed. If this isn’t something you’re aware of, the Wikipedia for it is linked. Please check it out ...
This seemingly insignificant predefined timeline can tank a project before it ever starts .... then the stakeholders lose faith in the project manager and developers.
When the time constraint has been determined before the scope and cost can be determined - the triangle is no longer balanced. This causes the quality to suffer. A LOT. The developers are forced to cut corners and not write bulletproof code that has all the basics code blocks should have.
Requirements for “Quick and Dirty”
Nice to have when there is time
Refactoring and troubleshooting
User testing / beta group
Consider future code maintenance
Separation of responsibility
Small code chunks - frequently verify with mocks and stakeholders
Research potential better ways for new processes
These lists are realistic and things I’ve had to do because of unobtainable timelines. Everything in both lists should be required in a new build or new feature. However, when we are given a shorter time to build your vision, we have to cut corners. Or lose sleep, which then causes us to miss dumb stuff and we end up with avoidable bugs. List #2 is what can suffer and be put into “Phase 2“ .
It will always 100% benefit you, me, the stakeholder, and the end user to let the developers build the timeline and estimate the delivery once they have fully understood the scope of the project and what the end product visually looks like in mocks.
It will always be better to estimate a little longer to account for unknowns and then deliver ahead of schedule, rather than always delivering late. If we estimate an extra month to complete a new build, the end result will be what you want and not something hastily put together. You get bulletproof. Generally speaking, when this is explained to stakeholders, they understand a little extra time will give them a huge value and higher quality products.
We want to work together to make a damn good product. Our names are attached to this too so we want it to succeed. Let us help make this project turn into the fold it deserves to be 💜
Developers, Engineers, Coders, Dreamers