Software has eaten the world and your business too. We will be addressing three major constraints and challenges to software delivery for your business in our blog series, starting today with…
Time Constraints and Deadlines
Every business involved with software has a short-term plan or strategy if you may say, that requires code to be written in a particular time frame. Planning is a legitimate affair for any business, and so is putting tentative dates on them.
However, what is not legitimate is that they assume that some piece of software that they have in their planning can be delivered on the planned date without considering the state of existing software, the team capabilities and without roping in the engineering team into those planning meetings.
Looking from the other side, engineers might not like to be in those meetings, and with that mindset they are never the useful in those meetings either. Even though it is an ideal situation that engineers see the bigger picture, time and again it has been proven that they do not always do that. This might not be the right thing, but it is what it is. Engineers are excited by bits and bytes, and not by financial statements and business milestones.
From an engineer’s perspective, the deadline is unreal. From the business point of view, the deadline is important. So, what we are actually dealing here is with an unreal but important date to be met for the software piece to be delivered.
If we can fill this gap of unreal but important date, we can meet the unreal important date. This requires taking a step back and rethinking on why has this never worked well in the history of software development and how can this be addressed.
Solving the unreal but important deadline syndrome?
As a business you need software to do certain things in order to accomplish a business goal. The business goal is important and the features you are recommending are unreal. It could be unreal from a technology standpoint or time-wise. It is the business that makes things unreal. Let’s accept it. You should not be deciding on that.
The meeting you need with your engineering team is to share the business goal with them, the timeline you have in your plan and work with them to come up with the correct requirements. This is in contrast to getting your CTO or the engineering team in the business planning meeting altogether.
Business goal is to allow your application users to create a deep profile page. You want it done in 2 days. Of course 2 days is unreal. They would say it is a 2 week project. However, now that you have shared the purpose, they might be able to recommend that they could import people’s LinkedIn profile, and showcase all the details available and only put a design together and show all of that information in 3-days’ time. That creates a purposeful certainty.
The focus shifted from pushing to meet a deadline to creatively thinking on accomplishing the purpose in the needed timeline. You are empowering your development team to help you make decisions, and are laying your trust on them. Apart from solving the business problem of delivering software on time, now you are also improving the synergy with your development team. You have roped the engineering team into the business world by discussing an engineering problem. Now that even though they do not fully comply, they have a feel for the big picture and are going to be completely aware of it. Partial problem solved!