Steal: to take (the property of another or others) without permission or right, esp. secretly or by force.
Thief: a person who steals, esp. secretly or without open force.
I’m sure most of you are familiar with the verb (Steal) and how it is used to describe the spiteful act of the noun (Thief). I’m here to talk about a thief who stole from my company, directly attacked our employees and has tarnished the image of the offshore outsourcing software industry in Pakistan.
Custom application development firms like ours are usually engaged in providing software development services through a fixed time fixed cost contract. These are typically 3-6 month long projects after which support and maintenance services are provided as mandated by the SLA. Projects that require more than 6 months of development, or where the customer wants the offshore team to work with the onshore (local) development team often choose to go the ‘Dedicated Resource’ route. With the dedicated resource arrangement the development team works exclusively for the customer on their project. The Project Manager is responsible for being the bridge between the customer and these dedicated resources. His job is to make sure the work gets done according to the satisfaction of the customer. This model works very well for both the customer and the offshore company. Until you hire a rotten apple – a thief who after establishing a rapport with the client decides to steal your customer.
Read more…
I never went to business school and never learnt management. I was a software engineer and was entrusted to manage people in 2002 when I took over the family travel business. We were a small team of 15 people and I ended up doing everything – including sales, marketing, operations, hr, accounts and admin. For one – I enjoyed the problems these verticals presented. They were challenging and I was learning new things. Two – I found that I couldn’t trust anyone to do them right – people were either incompetent or lazy. I felt I could do them better, faster than anyone and get better results. Between 2002 and 2005 I worked 18-20 hours a day. In the process I became a control freak. I tasted success – the company grew to 70+ people. I started a bunch of other businesses, took up a position at Creative Chaos and ended up having about 140 people reporting to me. Soon afterwards I became a victim of my own success. Nothing was getting done because everyone expected me to do them. Surely I couldn’t do everything. It was impossible! I ended up spending 2 hours a day at each of my 4 offices – firefighting and delegating problems to people who had little confidence in themselves! We lost a lot of business opportunities, clients and money.2005 was the roughest year I had as an entrepreneur.
Read more…
I’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 delivered – not 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.
