INTRODUCTION
In the first part of the cycle, we talked about initial estimations (in our case project concept) and characteristics of a good leader based on the first chapter of Sun Tzu’s TAoW. Since we established that the preparation for the upcoming new challenges is crucial in terms of accomplishing success, we can now move to adopt a strategy and adjust tactics to our situation while still focusing on our ancient guidance. So let’s try to examine in this light the second and third TAoW chapters!
Waging War - Strategy
The second chapter of TAoW is focusing solely on a concept of waging war, estimating available resources, and how to avoid weakening your army by running out of them. Of course, we don’t have to gather a thousand swift chariots or a hundred thousand mail-clad soldiers, thankfully. Nevertheless, we have to be able to predict how many resources will be needed to complete our campaign - we need to create a project cost estimation.
"He who wishes to fight must first count the cost"
The key to estimating it properly is to prepare beforehand, just like we said in the previous part. The knowledge of what to expect is crucial. It allows us to evaluate how many troops we need to assign for the whole operation and also how to provide for their subsistence. In our case, the base of estimation should be an in-depth discussion with our client. It’s not uncommon that our customer can table indispensable cornerstones of the project that are reasonable, but it’s getting harder for him to describe the smaller elements that might not seem important at first sight (or even unnoticeable). It’s our job to extract as much information as possible, mainly by asking a lot of questions. Those questions are intended to enable us to better understand his expectations and the amount of work that will be required. It’s worth keeping in mind that this estimation won’t be certain. It’s more about predicting the cost than counting the actual cost.
After getting all the information that we could get from our client, we could now prepare some scenarios of how using the actual app would look like. I mean, of course, well-known user stories. Those are short descriptions of functionality told from the user's perspective - user cases. The idea behind them is to organize work - basing on them it is easier to section off smaller parts of tasks from the entirety of a project. “Ok, but why are user stories important while estimating resources?” - you might ask. Well, I believe that they allow specifying all of the moving parts within a project, their inner connections, and the order of completion. They help to ensure that none of the aspects of a project are overlooked and every one of them is properly tested. From the customer’s perspective, those initial user stories could be helpful after the project is given to him, simply because he can recreate any of them to find out if requested features are present and are working as they should be.
But user stories are not everything we need to prepare accurate estimations for - we need to go deeper. For example, one of our use cases could be the need to log in to the app by our user. It’s pretty simple, right? But what has to be done to make this possible while making it a pleasant experience? It’s required to design the UX interface, prepare the graphic design of the site, and implement code responsible for the validation of data put by the user in the given fields (at least). So basically we have to divide all of the use cases for smaller tasks and THEN we can think about estimating one case after another. This approach allows us to make predictions that are closest to reality. Without focusing on all the smallest factors it’s possible, that we could draw our estimations right out of the hat as well.
As I said in the previous part of the cycle, we can also align ourselves by using different methods like building BPMN diagrams or creating a schema of the project. Finding the right tools shouldn’t be a problem - there are already plenty of them all over the Internet, and many more still emerging (just like GraphQL Editor mentioned in a previous post for creating GraphQL schema, documenting it etc.).
But even if we manage to prepare a lot of information and ancillary materials there is always a risk of a huge under/overestimation. It’s a human factor. That’s why it is always safer to go through initial estimation with other members of your team. Sure, the estimation of every task won’t need to be double-checked but look from other perspectives will allow us to minimize the aforementioned risk.
All of the above sound nice and easy, right? Almost ideal. It is, but it requires almost ideal conditions as well - time and budget, that could be strictly limited. For example, our client knows what he wants from his potential app, but has little to none idea what should this app contain and how to execute this. On the other hand, he seeks to apply for donation and there are just a few days left to present the cost predictions to the granter.
So what when the customer that wants to engage in a project does not have enough time or other factors are in the way of preparing complex estimation? Well, assuming that our customer has limited resources, skipping estimation altogether would be a mistake because it could lead to stretching his budget a lot in the future and not meeting the set deadlines. Instead, we could make use of our experiences with other projects and try to guide our customers with propositions based on them. A whole lot of projects have some similarities.
Let’s take the previous example of a user's login into an app - that’s pretty common so most PMs and their team members know how to handle that. The same goes for things like online payments, placing an order, etc. Using those experiences might let us focus more on unique parts of the project while not letting those other parts slow our progress down.
But it is possible to make the process of estimating simpler and shorter. It won’t be as accurate of course, but it will give us the overall picture. In this scenario, it is very important to determine as many general aspects of the project as possible by communicating with the client. It’s even more important than in our close-to-ideal scenario before. Why? Simply because we now should be focusing on the bigger parts of the project and we can assume that we will have to take care of the details. At this stage of the project, it might not be important, for example, how something will look like or how, let’s say, restoring a forgotten password would work. Based on information acquired from the client we can now prepare, you guessed it, user stories. The difference here is that we won’t be splitting those user stories into smaller tasks to estimate them individually, saving us some time. And doing that shouldn’t be that hard - a whole lot of projects have some similarities between them, just like logging into an app in the example mentioned before.
I have stated before (twice already and I can’t promise that I won’t do that in the future) that using other tools, like:
- creating a schema,
- BPMN diagrams,
- preparing mockups.
All of above could help us to guide our project from the beginning and estimate the costs. I stand by it, but it is worth saying that using those is not essential. When the circumstances aren’t as we hope for them to be, we can skip them and go back to them at later stages. It will allow us to create a faster, but slightly less precise estimation.
“Thus, though we have heard of stupid haste in war, cleverness has never been seen associated with long delays.”
According to TAoW a country never takes advantage of prolonged warfare. It can exhaust the country's resources to a minimum and bring many to a fringe of poverty. Maybe poverty itself is not a real issue in our case, but it definitely could influence the financial state of our company. That’s why we should prevent stagnation in our project - this includes preparing estimation. Sure, the first approach that I talked about in this article will prolong the process somehow, but the key is to try our hardest to make this swift. For example, an email exchange with our customer that was supposed to bring us more light on the project could take days, taking into account that it is not our and our customer's only seizure. I know from my experience that setting up a call or meeting with a customer in person might be way more efficient than sending a bunch of questions and waiting for a response from the other side. The key here is to come prepared, so before the said meeting ask yourself a bunch of questions about the specific parts of the project. For example, if the user of an app should be able to create an account in it, then those questions could look like: “What data user is supposed to fill-in? All of that data is supposed to be editable or just only some fields?”. This will help us to stay on topic instead of conducting a meeting about every small piece or the subjects that are not that relevant (at the moment at least). Also, a lot of the previously unspoken issues can come up during such a short meeting so we could say that profit coming with them is double. If that’s not an option, then try to make your emails to be as precise as they can be and point out those aspects of a new project that need to be discussed more further. While asynchronous work is the approach to go with by default, it is worth realizing that there are some scenarios when actual talking live could be more fruitful.
So, to conclude, how exactly should we choose “strategy to adapt and tactics to adjust to”? Well, it depends. Just like a commander of an army, in the face of a new challenge, we have set goals to accomplish while making sure that those goals are achievable. That’s why we need to be fully aware of the resources to our disposal and tailor our plans according to that knowledge. By following the same approach in every situation we expose ourselves to a risk of losing otherwise winnable battles and, in the long term, even a war.
Keep in mind that's my interpretation of a second and third chapters of TAoW. I'm aware that many of you will have different thoughts about the subject and I'm really looking forward to read about them in the comments section!
