Project Timing and Deadline Compliance
Project Timing and Deadline Compliance
Here are some ways for developers to reach the deadline even if everything goes wrong and resources have shrunk dramatically.
Join the DZone community and get the full member experience.Join For Free
What's the Problem?
Programmers almost always snap deadlines. The work is creative and it is impossible to predict up to a minute. A separate headache of PM is when a programmer has done everything faster than the deadline, decided to improve something because of his perfectionist ambitions, and in the end...that's right.
There's always a problem with deadlines. The scientific experience of the project manager brings the internal deadline and client deadline for at least one week. There is always a time scale, deadline, and a list of tasks to be completed by that time. Sort of planned, everything goes according to plan. But then, all of a sudden, the programmer gets sick, the designer gets into an accident, and the front end developer has a burnt SSD. All our plans go to the garbage.
The failure of the deadline on the market of website development and mobile applications is, unfortunately, stability.
While interviewing for the position of a project manager, I asked the candidates: What do you do with the deadlines? The answer, as a rule, is "Well, nothing, just watching." Well, this is not normal for the client. There are an advertising campaign, investor issues, and a lot of other obligations.
For example, there are 10 programmers on the staff, one of them is ill — the output is reduced by 10%. And if some epidemic and 4 developers fell ill at once, it is 60% of project development.
You have to explain to the client that this situation is force majeure. In such cases, of course, they try to find a way out, to involve third-party developers. There are situations when the deadline breaks down.
When Deadline Is Critical?
There are always projects where the deadline is critical, for example, the tourism business. If you started advertising later, ticket sales have already taken place, and you sit and collect the rest and get as a result only 30% of what you should have earned.
With the startup, the story is even worse, as there is strict reporting to the investor. For example, you have the first of March, the date of display of ready-made software on which the advertising campaign is launched. Postponement inevitably leads to an unpleasant conversation with both the investor and the advertising contractor.
How Do You Keep Your Deadline?
Let's get back to the way we keep the deadline. In the event of force majeure, we must understand and accept that your metrics have already floated. It's important to figure out which of the three most important parameters you'd like to make worse.
- Launch time with the same price and volume of functionality. This is a deadline failure.
- The price, with the same term and functionality. This is when you take an expensive replacement with a surcharge for urgency, instead of a dropped out production unit.
- Functional, at the same price and time. It's when we cut off something not very important to the deadline.
The last point is further on.
The work plan for 6 months can be completed in 6 weeks. It doesn't mean that the programmer will work 24 hours a day, you have to track workload, it means that we simplify the requirements by excluding non-essential functionality.
Let's look at an example. We have a product marketplace. We need to make a supplier card, the supplier has a range of products, each product has a card. There are only three screens we've planned to make in a matter of time:
- Profile of the supplier
- List of goods
- Detailed product card
Let's say something incredible happened and we only have time for one and a half screens. We make a supplier card (suppose this is the emphasis in this project). You can't put it anywhere. You can add a list of products to the supplier card below and not make a detailed view of the product card and add this or that information on the same list.
You get a longer list with a "buy" button in front of each item. We have simplified the volume of work, but the key idea and business logic are preserved: you can go to the supplier and buy a product.
Option number two. If a product has a lot of information and cannot do without a card, you can do all three screens, but do not screw the basket and acquiring — in force majeure mode, you can send orders to the post office manager, and he will put out an invoice.
It's a more concise version than planned from the start, but with force majeure in mind, we sacrificed more convenient deployed data but maintained stability throughout the project. We got into the deadline, we made the key function, we can develop the project further.
The main feature of this principle is that by the appointed deadline you follow the key business process, but leave only the most important things and sacrifice, in the case of force majeure, what is not important.
I've seen several examples of such applications. We made the project a "short" way, launched it on the market, pumped the traffic, and did not do what we had in mind in the beginning.
Opinions expressed by DZone contributors are their own.