Home > Project Management > ‘To date or not to date’ – How to make sure that your project fails before it even starts

‘To date or not to date’ – How to make sure that your project fails before it even starts

January 26th, 2008 Umair Aziz

watch_close.jpgI’m looking for project managers to help me out with some new projects. I have interviewed at least 25 candidates in the past couple of months; some with just 6 months and some with 16 years of experience. I always ask how these managers estimate time and effort and come up with release dates for their software. As expected, 90% of the candidates tell me that the release dates are dictated to them by ‘their management’. Which leads to my next question – so how does ‘their management’ come up with the date? What is their estimation technique? The typical answer has been that it is a function of how urgently the client / product marketing wants the application and the experience of the firm in developing similar applications.

Most of these managers I interviewed confessed that they have usually taken these dates with a pinch of salt. They protest – but in vain. Some break through and are able to buy a few weeks. However I hear the same story over and over again that their CTO, product marketing, business management and customers drive release dates. And just like that – all the time -managers all over the world are taking on a date thrown to them by a bunch of people who are not active developers or don’t understand how software is developed. The development teams (and their managers) think they will be heroes if they accept the date and then make the release on that date. Developers are skeptical at first and will tell you it is a difficult ask. The project manager will persist telling them how much confidence the management has in their capability and the fact that it is a challenge makes it a perfect opportunity for them to win and shine. Think recognition….bonuses…promotions.Most developers live in a fantasy world and think that they are ‘supermen’. It really doesn’t take much to convince them to take on un-realistic deadlines. Just keep telling them how super important / business-critical the task is and that if they try hard they ‘can do it! Yes it will require late-sittings maybe even some weekends – but it will all be worth it at the end of the day. A great product will be released on time, customers will be excited, money will roll-in – and management will laud the heroics of the development team!Thus the project manager marshals his troops into battle – knowing well that the road ahead is difficult however is convinced that his team of supermen who have ‘accepted the date’ will ensure that he becomes a hero too.Back to my interview where these project managers think their management pulls dates out of their ass (excuse my french) – and makes them look bad when they can’t deliver on time. I ask them what they want and what should be done? To my surprise and disappointment all of them tell me they want control over the date. They tell me that with the help of developers they can now come up with better estimates. And since the developers are now involved in time estimation – we can be hold them accountable and responsible.I tell them I can give them anything they want – (even unlimited resources!) – however everyone seems transfixed on the date and wants control over it. They truly believe that the solution is that management and client give up their right to setting release dates and hand it over to the project manager and the development group. This is the only way we can ensure that our project doesn’t fail.As logical as their request sounds – it is sadly unrealistic and impractical. Developers and project managers can never have control over delivery dates. These dates are tied with revenue and allow these companies to maintain cash flows and pay their monthly bills. No matter how good a reason developers give – if a company needs to realize revenue in a given quarter they will make sure a milestone release date is set in that term. Unless you are Microsoft (who just delayed SQL 2008 by a year) – the financial repercussions of moving release dates is tremendous.And that is why project managers and developers can never and should never set release dates. Since no one has unlimited resources – project managers have to work with time and resource constraints on any given project.Project managers should fight over what will be deliverednot when. The stakeholders of the project (management or clients) should tell dates that matter to them most. These dates are business-critical and should not be tampered with. Stakeholders are also responsible for creating a prioritized list of workload. We must know which features are most important and which are the nice to have items. Project managers should then work with the developers to create a set of iterative releases based on the release dates provided by the stakeholders, focus on the most important features and deliver them when they are needed.Project managers should be telling stakeholders that they can deliver say 6 out of the 10 features by their given date. The stakeholders get to choose which 6 features make it in the release. If the stakeholders insist on all 10 features and say all are business critical and must be done within the allotted time – project managers should walk away. They want you to be a super hero and if you don’t have special powers like batman and superman chances are you’ll be working hard – beating yourself and your developers to death and finally getting rewarded with a pink slip at the end of the project. Note: I’ll be writing more about stakeholders and how project managers should estimate team velocity, identify release work-load amongst other areas in future articles.

  • Share/Bookmark
Categories: Project Management
Comments are closed.