Working in the software profession you will often run into a situation where someone is pushing your estimates down, asking for the moon, or increasing scope without adding resources or time. There is no instruction manual for handling that sort of thing. The only thing you can really control in that situation is how you respond. I’ve learned a few skills over the years that help.
The fundamental law governing all projects – the Iron Triangle:
Probably the most widely accepted concept from project management is the ‘iron triangle’. The corners are:
- Scope – what does the project consist of? Includes QUALITY of the work!
- Schedule – when will the project be released?
- Cost/resources – how many dollars and or hours are available?
The law of the iron triangle: when one corner is reduced at least one other corner must expand to compensate. Every conceivable way to cheat this law has been tried.
Another way of looking at the iron triangle is: better, faster, cheaper – pick two and you’ll be fine.
Feeling the squeeze and reacting with empathy:
Normally balancing the triangle is in direct conflict with a project being seen as profitable or successful by at least one if not multiple stakeholders on a project. Invariably someone is going to want to push on one of the corners. You’ll be asked if you can do it sooner, or if you can do it with one less team member, or if you can launch it with just one extra feature. The important thing is not to take it personally. It may be their job to do so, perhaps a performance evaluation or paycheck is on the line? In the famous Getting to Yes book, one of the things that has always stuck with me is separating the people from the problem.
The naive and closed off way of think of those who push you around might be:
- The CEO with the personality disorder
- The sales person who lied about the system’s functionality
- The project manager gunning for a promotion
- The team member who insists on using language X
- The team member who insists on staying with older technology
Instead of using labels, the wiser path is to see them as people who have shared goals with you, who want what they think is most important.
- The CEO who is self assured and wants to ‘win’ (which is good for you)
- The sales person who is always upbeat and optimistic (without sales, the software is irrelevant)
- The project manager who bases their self worth on their accomplishments
- The brilliant and eager developer who wants to use language X
- The experienced and cautious developer who trusts what they know
Negotiation skills for getting out of the squeeze:
For most senior software professionals, it is second nature to refer back to estimates, bring up concerns of quality, or tactfully point out how rushing in the short term leads to bad outcomes later on. If all you offer is ‘pick two’, or ‘it is impossible’, you are right, BUT whoever you are talking to is coming to you for a solution not a dismissal. Here are some techniques that have helped me deftly get out of pressure situations while making the customer happy:
a) Soft launch / beta release: Release the software in a partially complete state to a very small number of trusted users. Finish up everything else as more users come on board. This allows the schedule to flex some, and possibly even the resources, but keeps the scope in tact.
b) Start a road map: Setup a long term plan (1-2 years) which covers all the necessary features. Illustrate any changes to resources, scope or schedule on the road map so the trade offs are apparent. Some advantages to having a road map are that everyone in the company can setup the 1.0 features in a way that leaves room for the 2.0 features down the line. Of course, leave room to clean up bugs and technical debt along the way and make it clear that when these get left out they will come back to steal resources later on.
c) Primary deliverables and secondary deliverables: Primary deliverables are must have items. Secondary deliverables are things that are needed, but don’t take immediate priority. Usually items like report pages, admin screens, data exports, and print friendly pages make great secondary deliverables. Coming to an understanding over what items are the most important can be a huge breakthrough in communication.
d) Make room for technical items: Every release, include at least one or two technical cleanup items. Politely insist on these items at every planning meeting. Explain the consequences of not following through. An example – the SSL certificate on the API is going to expire in 6 weeks. Unless that is updated all users will get locked out of the application.
e) Be honest about your limitations: It can be hard to admit you need some help or that a specific part of the project isn’t suited to your skill set. For rock star developers it is tempting to take on everything all at once. I always tell people – I can’t pick colors or draw… for the sake of the product let’s get a designer on board sooner than later so I can implement what they come up with and we can stay on schedule.
Another tool – Non Violent Communication:
This post was inspired by the book Nonviolent Communication (NVC) by Marshall Rosenberg. NVC explains a formula for effective communication.
As a software developer I liked the way it was presented as a ‘recipe for communication’ with lists of wording choices.
The basic formula is:
- State observations that are objective in nature and seek clarification.
- State how those observations are making you feel using specific language.
- State your needs.
- Make specific requests so your needs can be met.
Here is a list of descriptive ‘feeling’ words: https://www.cnvc.org/sites/default/files/feelings_inventory_0.pdf
I don’t know if statements like “i’m feeling enchanted“, or “i’m feeling wretched” are 100% work appropriate, but the idea is to be very specific about how you feel so the other side opens up.
NVC Applied during an ambush:
One day early in my career I recall being cornered in front of a white board by multiple senior managers. They insisted I launch a product by a certain date with a certain set of features. I told them the original estimate of four months was what it would take to get it done. They kept asking me questions like “what can we cut?”, “how can we do this cheaper?”, “is your estimate for that already padded?”.
We looked at every aspect of the project together. It went on for an entire afternoon. Every design decision was scrutinized. Fundamental items were scraped. I walked out of there feeling drained and wondered what kind of people I worked for. In hindsight they were struggling to deliver on a bad promise they had made, all with the best intentions. The project ended up working out fine. I didn’t have to work evenings and weekends to get it delivered. Later I went on to clean up some of technical debt in subsequent releases. Then I took another job (where I stayed for a long time) and washed my hands of the whole code base.
On that fateful day, had I known about the tools from Nonviolent Communication, I could have done the following:
1) Make observations:
Wow, hang on a minute here, let me catch my breath! I’ve noticed everyone is pushing hard to make this project as cheap and fast as possible.
1b) Seek clarification:
What changed? Did we loose funding or did a customer back out?
Are you sure you want to do without feature X, my concern is that is an essential element of the project.
I’d like to know what Joe from down the hall thinks about changing feature Y.
Maybe we should we call in project manager Jane to provide some input because my expertise is in software not project management?
2) State my feelings in a clear manner:
I’m feeling lost because our commitment to quality and customer satisfaction can’t be upheld when we rush through our work. I’m also feeling flustered because non-technical people are overriding the technical details of a product I am responsible for.
3) State my needs:
My needs are to deliver work that is complete, done to the best of my abilities, and aligned with what my manager and the business expects of me.
4) State my requests:
Would the leadership team be willing to phase in everything in my original spec over a 4 month period, with a soft launch in 3 months? Would the leadership team be willing to allow key technical items that ensure quality as part of each release over the 4 month period?