Daniel Cieckiewicz
Estimations in our IT World are very, very important. They can be an accurate indicator of company success. Why? Because if assessments are inaccurate or made with haste and inattention, the project can be unsuccessful – to say at least. If projects are unsuccessful, there will be no money coming to the company. Technical experts will leave the company because they will be blamed for inefficiency. The atmosphere will get toxic and distant. The HR department will be blamed for the people leaving. And so on and so on. Just a couple of really bad estimations can cause a stream of failures.
I had experienced very bad and inaccurate estimations, and after every failed project, I wanted to say one thing – NO MORE!
I share 10 steps of a good IT Project estimation in this article. These are my best practices on how to work with IT Project estimations.
Let’s go!
In this article:
In this article, I will use word estimation in the context of the time required to implement and manage a successful project. Please be aware if I will use the “make estimation” or “estimate something” phrase, I mean the time, not costs – because costs will be different for different countries, companies, and adopted methodologies.
1. Plan your estimation activities
It’s essential to have your estimation activities planned. I should say it’s necessary to have your work responsibilities planned. If you do not have time for different – smaller tasks (and they will still be required), you will not be able to handle them, you will not finalize them, or you will not complete them correctly.
I understand that we often have our own project / management / leadership / consulting / administration / HR tasks and priorities. But planning other activities (not connected to the current project) is essential. It doesn’t matter what methodology you use for your work – Agile / Waterfall. It is always good to look forward and estimate different types of activities.
Remember also about risk and consequences. Let’s say you have essential responsibilities in your current project and cannot afford time for an estimation. But someone comes and offers you to estimate implementation hours needed for the upcoming project. You know this is an opportunity for you, and you want to take it, so.. you took it. Now, you have a problem because, within your working hours, you will not be able to finalize those two things: the current project tasks and the estimation. So, you are working overtime or not buckling down to the given tasks. There is a risk – if the analysis is incorrect, the incoming project may not be successful, and managers will blame you. Remember about this – think and plan actions before you agree to something! What is also essential – if you don’t have much experience with project estimations, allow yourself some more time with an estimate.
If you are already an experienced “estimator” – an architect – delegate them more often to invest more time in reviews and support. You will have more time for more challenging activities. And other people will learn something new.
To finalize this topic, remember to plan your work responsibilities properly.
2. Understand the process and provide improvements
Try to have the best possible understanding of the process you are estimating. Don’t be afraid of asking questions. Organize sessions/meetings with stakeholders to gain knowledge about the goals they want to achieve.
I enjoy my job the most when I believe I do something useful. If you approach the problem seriously and care about the outcome, it will get noticed, and the Client will be more committed to helping you. You probably already know that if a Client is committed and is helping – it is already a real accomplishment. Then, you will enjoy your activities more and be happier. Think about this.
Another significant factor here is the approach. Think about the way you want to address problems. Maybe drawing a diagram would be suitable for understanding the flow. Perhaps you need to learn how to draw UML diagrams. Improve your skills and make use of them. If you are new in this estimations world, try to work out the approach and best practices that suit you best.
During your work, try to improve the process. If you see areas that require improvement, you can always point them out. Suggest an improvement and explain it to stakeholders. Highlight the risks, challenges, and also advantages of an improvement. If the time required for the implementation will increase, try to convince owners that it will be beneficial in the end. If it will be beneficial 🙂
In summary, understand requirements, processes, problems, and challenges. Don’t avoid hard questions and talk to stakeholders.
3. Make notes - understand and remember more
It has been proved that we understand and remember more if we make notes. So, don’t be afraid to make notes during meetings, planning, and conceptional work. Draw diagrams and visualize problems and bottlenecks of the process.
This is not a very complex point 🙂 Make notes, so you remember more and have your thoughts, requirements, and plans written down.
4. Translate requirements into the adopted convention
There are many approaches and conventions for laying down requirements. Try to align with stakeholders’ appropriate direction so everyone can understand given requirements and tasks.
If your company has its convention – use it. Having common ground while working on a specific task is always good. If your more experienced colleagues use the “As a User, I can..” or “As a Manager, I can..” convention – use it and translate requirements, tasks, and system behavior using the accepted approach. I don’t know if these conventions have their names, but this one presented here is the most known to me; it works pretty okay.
I am sure there are different approaches as well – be sure to use one, so you know what your work’s outcome should be.
Just avoid chaos during your work with requirements so that they will be more understandable and straightforward.
5. Break down requirements into smaller pieces
Break down requirements into smaller pieces to estimate them more easily. If you have a requirement like: “Set up a database,” it is good to break it down into smaller pieces. For example: create specific tables, relationships, views, and more. These requirements will be much easier to estimate.
Another example can be a requirement saying: “As a User, I can view my orders and provide changes to the chosen order.” You can approach this requirement by breaking it into several smaller pieces.
The first could be: “As a User, I can see a list of my orders.” The second would be: “As a User, I can provide changes to an already created order if it has not yet been sent. I can pick an order from the My Orders list”. Please note that I have added another critical piece of information to the second requirement. I wrote that an order can be changed only if it has not yet been sent. From the previous requirement: “As a User, I can view my orders and provide changes to the chosen order,” I didn’t know when a User can edit an order. I asked stakeholders this question, and we figured out that an order can be changed only if it has not yet been sent. That’s why it is essential to go through the requirements and break them down.
By following this process, you find those problems and can address them before the implementation begins.
6. Choose technology
After your requirements are all understandable and straightforward, you can start thinking about the technology you will use for implementation. I am assuming that if you are estimating something – you are an expert in a particular technology, and you know that most requirements can be addressed.
So, make assumptions about what can be covered by your technology and where you see limitations. If you don’t know how to estimate some areas, ask for help.
For example, if you don’t know how you should approach integration problems, it is okay if you ask for help. Please don’t risk it and estimate it with a professional.
Very often, people don’t know how to estimate a functionality they don’t know how to implement – they are just not experts in such areas. To overcome this and still finish an estimation, they increase the hours needed for implementation, not knowing if that will help. They ultimately don’t know if this feature will require much implementation time. Don’t do that – be sure you understand why and how you estimate things.
Regarding technology, it is perfect for making an architectural design of a system, so you, Project Team, and the Stakeholders can better understand the interactions between components. Architecture design also helps identify potential risks and missing elements.
7. Define required resources - Project Team
When requirements and technology are set up, you can start thinking about the required resources for a project. You can make assumptions and choose who will be needed for such a project so that the system implementation can be successful. Project Owner, Project Manager, Developers, Quality Assurance Engineers, Consultants, SCRUM Master… You have to decide who will be required, who will not be necessary but would be good to have, and so on.
Create a Project Team that can handle implementation, deployment, and management. Please also make sure that the quality is top-level.
Defining Project Team is not only about completing people with specific skills. It is about their skill level as well. During this process, consider whether you will work with Juniors, Regulars, or Seniors. For a Junior, a particular task can be more challenging so more time will be required. To finalize an estimation, you must know how many hours a developer needs to implement a feature fully. And to do that, you must know who will be a developer. This is why this step is crucial.
When this process is complete, you should have the final list of people required for the project, so after that, you can start working with cost estimation.
8. Estimate
Finally, we are at the step of estimating things! We should be ready!
Now, we:
- know the requirements,
- know the process,
- discussed every problem that came to our minds,
- proposed improvements,
- translated that requirement into the accepted conventions,
- broke down requirements into smaller pieces,
- defined technology and the Project Team.
We made a lot of notes; we drew diagrams. Our notes are structured, and the requirements are understandable and straightforward. They are written down simply – so they can be estimated.
Now, we can start estimating the hours required for implementation.
Take your requirements and assess – How much time is required to implement each requirement in a given technology? Consider the impact of other components and required objects.
Remember that in a previous step, you set up a Project Team. During the estimation, remember the developer’s skill level that will be implementing a feature. Take that into account.
9. Include those things
Implementation estimations will not be fully ready if you will not consider things like the following:
- Requirements clarification – there are always questions during the implementation. You will not be able to second-guess everything. That’s why it is essential to assume some hours for further requirements clarification and additional meetings. I would call it Process Management.
- Tests – very often, in my experience, time for testing was cut. Not from my initiative but a reviewers/managers. I am a big fan of testing and ensuring we deliver a top-quality product. Don’t dump tests. They are needed. Let professional QA Engineers do their job. It will be beneficial. Also, remember about the testing strategy. If the process your team will be implementing is complex and advanced, it is good to align the testing strategy, so the proper amount of hours will be planned.
- Documentation – This is tough because no one likes documenting stuff, especially developers. But it’s very often needed. Good documentation will benefit your team and the Client, especially if the system is complex (as I said in a previous point). There are different types of documentation. Align with a Client which one will be required and plan time for this activity.
- Fixes – If you test a solution, there will be bugs, and bugs must be solved. This is an indispensable step in programming. Someone once said: “We invested a lot of time and money, we developed and deployed a system, and it worked for 5 seconds before it burst into flames.” We fix bugs to ensure that the system will work for a little bit longer than those 5 seconds 🙂 Plan those things. If you feel some features may be more challenging, assessing for more hours for development, testing, and fixing may be suitable.
- Deployments – this one is straightforward. Plan more than one deployment if you have created proper DEV | TEST | PROD architecture. Use your experience to assume how many hours are needed for a single deployment. It will depend on the amount of work and complexity of a system.
- Project management (ad-hoc meetings, SCRUM events, backlog management) – Developers love this step and SCRUM events, discussions, and backlog management. Just kidding 🙂 It is another indispensable factor of a system creation process. We must take care of our project backlog and manage and align our work to stay compliant with the methodology we work with and the stakeholders.
- RISK – last but not least. Risk is the thing that is very often too hard to estimate. People add more time for riskier functionalities. I mentioned that if you feel some features may be more challenging, it might be good to assess for more hours for development, testing, and fixing. But the risk is a different story. By risk, I mean that you assumed some feature could take up to 500% more time than initially estimated, or it can never work as planned. During this estimation process, we want no risks; we want to point out that risk before we finish an estimation. I also mentioned that you should not avoid problematic and challenging questions. Suppose you feel some features generate too much risk and can be very difficult to implement or maintain. Share your concerns with Project Team, Product Owner, and Stakeholders. I think that trying to estimate risk is a bad habit. I prefer avoiding it. Just remember that challenging doesn’t mean risky. And we want to avoid risk, but we don’t run away from challenges.
10. Ask for a review and finalize estimation
In this last step of good estimation, we ask someone for a review. To ask for a review, we must introduce the process, requirements, and other things to the reviewer so they can do their job correctly. Remember about things that must be precisely explained or that you are unsure about.
Align with a review of the outcome of an examination. Whether it should be a new document with provided comments or that person should work on an original one. Remember also about the actual number of hours assessed by yourself – so you can see if your estimation was precise.
After a review, organize a call with a reviewer, so you can talk about problems and adjust requirements or estimated hours. By doing this, you can understand what you are missing. If you can, ask for advice so you can do better next time.
After a review process, finalize your estimation and prepare the final document containing the following:
- a document and an estimation goals
- short process description
- a list of requirements
- an architecture design
- process flow diagram
- an estimation
- the Project Team
- estimation summary – including all additional time besides implementation.
If you can afford it, take a break between reviewing and finalizing an estimation for at least a couple of hours. It will help you in having a fresh look.
Summary
I hope you will find those best practices useful. As I mentioned in the introduction, those are my best practices combined. In my experience, I made a lot of estimations and encountered many problems. I want you to make excellent and accurate estimations so that the projects can be successful, and you can be successful too.
It was exhausting – grabbing those things and introducing them to you straightforwardly. I am not a master of writing, but I hope you enjoyed this list and learned something!
I have one last word for the Clients we are working with as developers and technical experts. Don’t always go with a solution that is the cheapest. Someone once said: “If something is cheap, it doesn’t mean it is bad.” I also trust this quote: “If something is expensive, it doesn’t mean it is good.” Find a balance between those two. Recognize the advantages of the proposed solution and analyze estimated costs. Point out the differences. Meet with the solution providers and make them convince you. Be governed by arguments and the approach, not the price. I was a part of projects that were sold because they were the cheapest and many of them failed. We couldn’t deliver a fully working solution within an estimated amount of hours. Remember about your risks. You can lose more than you think.
So, finally, we are at this point where I should thank you for your time and reading this article. Feel free to rate this article and comment if you liked it. If you have any questions, feel free to contact me (via contact@poweruniverse.org), but first, you may be interested in joining a Newsletter. Hmm? (Sign up here) If you already did, wow, thanks, thanks a lot 
Via Newsletter, I am sharing insights into my work, plans for upcoming weeks, and knowledge about Power Platform Universe and the IT world. If you are interested, feel free to join! I am going to send the latest Newsletter to everyone who enters!
See you!
Daniel Ciećkiewicz
I am a Senior Power Platform Consultant focused on Dataverse, Power Apps, and Power Automate. I was also a Team Leader responsible for the Power Platform Team and their development paths.
In my private life, I like video games, sports, learning & gaining knowledge, and a taste of good Scotch Whisky!
Ooo, I almost forgot, I love our Polish Tatra Mountains!
Power Apps Licensing Explained
Power Apps Licensing – this is something every Power Platform expert must know. In this article I will walk you through the cons and pros of available plans.
Understand Delegation in Power Apps
In this article I will walk you through delegation in Power Apps and I will show you many interesting concepts how to work with delegation and understand Delegation in Power Apps!
Connection vs connection reference in Power Platform
In this article I will tell you what is the difference between connection and connection reference in Power Platform. It is very good to know the advantages.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
The most interesting Power Platform features of 2024 – Wave 1 update
Do you want to know what updates are coming in 2024? This article will tell you more about incoming updates for Power Platform in Wave 1.
Use a Service Principal to run Dataverse actions in Power Automate
Do you want to learn how to use a Service Principal to work with Dataverse actions in Power Automate? This article is for you. Check it out.
Overview of a Tenant Isolation in the Power Platform
What is Tenant Isolation in the Power Platform? How does it work and how do you know it will be good for your organization? Check the article!
[…] articles help you grow your management and leadership skills. For example, 10 steps of a good IT Project estimation or Becoming A Mentor are articles summarizing my experience I wanted to share with you, so you […]
[…] articles help you grow your management and leadership skills. For example, 10 steps of a good IT Project estimation or Becoming A Mentor are articles summarizing my experience I wanted to share with you, so you […]