The Unusual Common Pitfalls for Planning Software Proposals & Projects

Did you think that a working day is 8 hours? Is your plan in weeks or in dates? Are you managing team members in different countries? Here are some tips & tricks from what I learned when it comes to planning projects!

Why do we care to plan software delivery? Why is it such a complicated job? I am not going for the cliche of "You need to plan for everything", and the typical stereotypical statements about planning for your meal, etc. etc. But I will describe it from a different angle.

I believe that: writing software code is an intellectual activity, it is like writing a book.

Now imagine asking someone to write a cooking book based on your taste, and the book needs to be delivered in a specific time, and we will need multiple writers working on the same book.

What do you think of the outcome? How much effort do you need to put in to understand my taste? Now you understand why it is such a hard job to build software (whatever this software is doing)… the bigger it is, the crazier it gets. That explains why there is so much science put into project management, selling, and later on maintaining software. You need a great maestro to deliver it, but no maestro is great without their team behind them.

And that's the reason behind why I always look forward to sharing any of my knowledge for free, so others don't fall into those pitfalls I fell into before.

This time I want to discuss some of the common pitfalls in planning, either for a proposal — like attaching a high-level plan with a proposal — or for a delivery.

Official Holidays — Not The Usual Perspective

I know it is a no-brainer, but I have seen some (not a lot) who forget about weekends — not the smartest, I know. However, the real thing that they usually forget about is the official holidays, especially if their team is in different countries.

Make sure you add the different holidays for the different countries for each resource.

TIP: Ask the team members themselves to share with you their country's official holidays.

How Many Hours Per Day?

I will talk about how to estimate a task + buffer, contingency, communications, etc. in another article.

All the PMs or pre-sales I worked with always estimate that the working day is 8 hours, so a task that needs 40 hours of work should be finished in 5 days — which makes sense to be honest. However it is not true and actually it is far from reality. I usually used to say that a work day is maximum 6 hours, which makes the 40 hours task to be nearly 6.5 days of work.

A similar study by career resource website Zippia earlier this year backs up the Blind poll. The company found that during an eight-hour workday, the average worker only spends four hours and 12 minutes actively working. The research, which polled 1,000 people, found that 47% of workers admit to surfing the internet and 78% of respondents said they didn't need eight hours to complete their daily work.

Source: "Nearly half of workers say they work 4 hours a day" (2024).

Leave Days

"But that leave will ruin my plan!", that is the PM's go-to, even if you are requesting it a month ahead. But when we planned the project we knew that each resource is allowed 21 days of vacation, and that as a human being they will take those 21 days somewhere. Why didn't you add it in the plan?

My recommendation is to factor in 1.75 days off per month per resource to account for personal and official leave — in case your country gives 21 days on average for example. Maybe a resource will take 5 and others will not, then it balances out.

Also be proactive and ask for all the "potential/tentative" vacation plans in advance, so we have an overview about when everybody "might" not be available or not and how to mitigate it as early as possible.

And for those who don't add a tentative vacation, encourage them to do it! (You will need them to take vacations for many reasons.)

Cater for different number of days off for different grades and their respective paid leaves. The longer the project is, the more important to factor this into your plan.

In Weeks Not In Dates

When you are building a plan for a proposal, build it in weeks, not in dates. When the plan is communicated to the client, there is a common pitfall where the client thinks that the date in the plan is the start date, so they have the wrong expectations.

Make sure your plan is in weeks, and in the assumptions you add that the project starts after the kickoff meeting.

Conclusion

These insights come from my personal experiences across various projects, from chatbots to complex integrations. Sharing this knowledge helps us all avoid the mistakes I've encountered and paves the way for smoother project execution.

Reflecting on these common pitfalls, it's clear that careful planning and an understanding of the unique challenges in software project management are crucial. By considering official holidays, realistic working hours, and leave days, you can create a more accurate and feasible project plan. Remember, planning in weeks rather than dates can prevent misunderstandings and set realistic expectations with clients.

Here's to building efficient, effective teams and successful projects!

References

It is all personal experience between the different projects I worked on, managed, and delivered. From chatbots to websites, to integrations .. you name it :)

Where Taqdim fits

Most planning pitfalls are really expectation pitfalls — between teams, clients, and calendars. The same kind of honest reading helps on the other side of the table: Taqdim helps job seekers read a posting honestly before they apply, so nobody commits to a plan that was never realistic. Taqdim is in closed beta. Join the waitlist.

---

Originally published on Medium on 18 May 2024.