There are five basic steps to be taken to build a good WBS structure.
First, start from the top of the building, then work down to the most detailed tasks. Structure is conventionally built from the top (major) to the bottom (minor). Elements (tasks) are quite similar to those used in Microsoft Word. This approach is commonly known as top–bottom access in scientific literature.
Typically, peak elements are precisely those elements that appear in the vision scope or charter documents of the project. Time and time again, you should ensure that management understands what you build in the project plan (using the WBS structure), because we repeat their objectives that are defined in these documents. Of course, assume that it will just be those high-level descriptive guidelines because, as has been said, the documents of that type are not going to be too detailed. Building a structure in a clear way is not easy, and the only correct way is using widely available software for project management. For example, a Microsoft project. It is hard to imagine that you will do all this correctly the first time, and there will be no change—work tasks will be moved and changed on a daily basis at the time of planning, and it's nice to have a handy piece of smart software that will make this easier.
Next, be sure to include the correct name for all of the tasks that end with a particular project delivery. Naming tasks is very simple—if you move from the delivery, then such a delivery requires the use of nouns—hardware, software, documentation, and so on. You also need to add verbs—setting hardware, software installation, delivery of documents, and so on.
The next step is to further upgrade and decompose tasks and to reapply the nomination process. Thus, for example, installation programs may consist of hardware and software code, or preparing hardware, test hardware, installation program code, verification program code, and so on. While this seems simple, it requires the involvement of all members of the project team, and as for the manager of the project, it will be difficult to know that all project tasks necessary to establish the project are successfully completed.
Usually, peak assignments can be defined by a manager or an expert, but after that subdivisions of the tasks are assigned to a team member so that all the necessary tasks are defined. Before this is done, it is imperative that the unified naming of tasks and task decomposition is adopted. It is interesting to note that this approach somehow buys the involvement of team members in the project because members of the team themselves define what they are doing and what their tasks expect them to do.
Remember to stick to the rules of 8/80. In fact, here, it is better to start with a discussion about the possible minimum or maximum duration of tasks.
I've seen tasks that last for several months and include several resources—but, then, such mega-jobs (wrongly called assignments) are more subprojects or projects themselves. These tasks are doomed from the start, not only making it virtually impossible to track their origins and the course of that certainty, but also making it impossible to obtain general information about the condition or quality of the task. Consequently, the golden rule is this: follow the 8/80 rule. It's very simple—none of the tasks should take fewer than eight hours, and no task should take more than 80 hours. That is to say, no more than one task should be worked on per day, and one task should not take longer than two weeks. Note that we are talking about two working weeks, which means 10 working days, not 14—unless your working week is defined differently.
Next, stick to the rules checkpoints. As with the previous rules, there are already control points; use these to limit the project's tasks. Checkpoints are usually defined and scheduled in advance as they are used for reporting purposes. Consequently, it is easier to report on the status of the project. Some authors say it would be nice to have weekly meetings and reports so that no task lasts longer than a week. However, that it is contrary to the 8/80 rule; it is up to you to determine whether such checkpoints have a point of reporting or a single checkpoint project (milestones). If you choose the latter, then things are clear, but because of the rules of project management, no task can last longer than the control point.
Lastly, there are other general rules for defining tasks. Other rules are not rules per se, but the outcome of rational decision-making by the group with regards to how to create tasks in the project. For example, the manager of the project will still have the best sense of how much detail to put into the development of the project's tasks. The manager may act as though the 8/80 rule is very intuitive and rational, but he may still want to micromanage certain tasks. Similarly, if you have problems with resources in the project, it is likely that you will adopt your own approach to a task.
Project management has been around for hundreds of years, although, of course, it has not always been known by this term. This just means that the project is similar or identical to one that has already been completed somewhere, and the question is how the project plan looks and matches your needs.
You can easily refer to the internet or another company regarding information about project management, and very soon you will have a sound project plan (or other documentation) that explains how to solve a specific task. This will also show how other people approach problem-solving. However, these templates may not always be the best solution for you.