Project management is a broad topic and includes many disciplines and processes. In this article, we describe common and popular project management topics that every professional should know.
What is Project Charter?
The project charter is defined as brief documentation that indicates the definition of the project, its objectives, scope, and participants in the project activity (stakeholders), as well as their responsibilities. The charter could include business needs, potential risks, and budget. Reference: “Project Charter – detailed real example for Project Planning phases”, https://www.policymatters.net/project-charter-detailed-real-example-for-project-planning-phases/ (Marta Cooper, 2019 ISSN: 1941-8280)
Why may you not need to do a Project Charter for your project?
Once we have clarified what Project Charter is, it is important to clarify the cases in which it may not be necessary. This type of case would refer to the development of software applications or digital products. Specifically for this type of development, the scope is a variable – it is not fixed as in the Project Chapter. In other words, the more we develop our digital product, the greater its scope.
Another variable in software development is the needs of the business, which are influenced by many factors, which can be briefly defined as internal and external.
By the same analogy, it will be difficult to define specific stakeholder groups. They would again depend on the specific stage of software development.
In this case, it is not necessary to do a Project Charter, because most of its aspects will change with the development of our software.
Scope of the project
The formally signed scope, in our specific case, would help us to get an idea of the specific requirements and the extent to which they must be met concerning the ultimate goal. In other words, the officially signed scope will give us an idea of what we call the MVP (Minimum Viable Product) and the work required to achieve it.
What will the signed scope not help you with?
The signed scope will not help with the potential risks associated with software development, which can be of various natures.
It will also not give a clear idea of the real requirements, which are generally much more detailed and descriptive than the scope itself. In this line of thought, the scope will not be as useful as possible in determining the actual work that is needed.
Scope creep in project management
Scope creep refers to the discrepancy between the originally defined scope of the project and the scope of the project during its implementation.
How can you avoid Scope creep?
To avoid the so-called Scope creep, it will be necessary to define it correctly at the Project Chapter level. After its definition comes to the need for good documentation and its control – that is, to establish practices to adhere to the predefined scope.
When will you not be able to avoid Scope creep?
The cases in which we will not be able to avoid Scope creep are those in which we do not have a proper and in detail defined and documented one. If we fail to control it as a result of major changes in requirements. Most often we observe Scope creep in extremely large projects in which the scope creep is identified as a risk.
Change management plan
The change management plan is extremely important. Otherwise, we would find ourselves in a situation over which we have no control. Reference: “Project Change Management Plan, a real example and template”, https://pm.mba/posts/project-change-management-plan/
In other words, not only will we go beyond the scope, but this will directly reflect on the budget, implementation time, and so on. In some cases, even the absence of such a plan would lead to scope creep and project failure. The lack of a systematic approach to change management could also lead to the termination of the project activity, namely due to the inability to control the objectives and scope.
Problems related to the project changes
This type of change can affect many factors of the project activity. Let’s start with the most important:
Scope – changes in the project can directly reflect its Scope. It is for this reason that we need to have a change management plan, as well as a clearly defined and documented scope to adhere to. More on the topic: “Change Management Plan: Example template”, https://wikipedia-lab.org/change-management-plan-example-template/
Time – changes in the project may have a direct impact on its implementation time. Some projects have clearly defined deadlines and if there are no practices for change management, the project may go beyond the deadline.
Budget – like time, the budget can also be defined and limited. The lack of change management can directly reflect on the set budget for the implementation of the project activity. When we have the opportunity, it is good to define a possible tolerance for change to make sure that we do not exceed the budget.
Product Roadmap – the many changes and the lack of their management can directly reflect the product we are developing. This is directly related to the scope, but also the long-term vision of the product. As a result of many changes, certain teams would fail to deliver a working product based on specific requirements, and this is the main goal.
Why you should have WBS
The need for a Work Breakdown Structure is extremely high. It not only allows us to segment the necessary work but also to get an idea of the necessary resources for its implementation. In this way, we will achieve a better plan for the implementation of the project activity, which we will be able to link with specific time indicators. Through Work Breakdown Structure, we will be able to more easily visualize the work itself and achieve easier execution given the detailed planning. Reference: https://www.workbreakdownstructure.com/
What is Gantt Chart and how will it be useful to you
The Gantt Chart is a real schedule that includes a list of the required activities of the project activity, the available resources, and the time required for their implementation. In this way, we achieve better visualization, but we can also observe the so-called dependencies between different activities, resources, and time. The graph also helps to monitor the progress of the project activity during its implementation.
Disadvantages of the Gantt Chart for a software project
The Gannt Chart in software development could be used to visualize the current tasks needed to develop and achieve a specific Milestone (or specific goals). The disadvantage is that it will not include information about the time required for bug fixing. As we already know, the defect rate is a variable that is characterized by the need for additional work, which cannot always be planned accurately. In addition, when using the Gannt Chart, it should be noted that it lacks activities that may arise as a result of a specific risk.
What we “monitor” in the “monitoring” in project management
Monitoring is one of the key phases of the project activity. Reference: “Monitoring and controlling program execution”, https://bvop.org/learn/monitoring-controlling-program/ (BVOP.org, BVOP Ultimate Guide)
It is most important to monitor the following parameters:
- Time
- Quality
- Scope
- Risk
- Resources (Staff)
- Costs (Reference: https://www.mmrls.org/budget-planning-with-an-example/ “Budget planning with an example” 2020 Rita Gavelis)
What is Gold plating?
Gold plating is a rather abstract concept. If we have to explain it more simply, it is about doing a specific activity or work to its perfection. Many people in their quest to do their job perfectly find themselves in extreme situations. This type of situation takes a lot of time, budget, resources, etc. Precisely because of the abstract understanding of the concept of perfection, gold plating is often identified as a risk factor in project activities.
Pursuit of the perfect design
This can be a situation where designers strive to create the perfect user experience in a specific software product. To do this, they can make too many wireframes and concepts to offer to the main people who need to make a decision. The result is rather confusing for them.
They spend a lot of time in work that is not necessary and it does not even help them make the right decision. To avoid this type of situation, we need to clearly define expectations as well as deadlines. In this type of situation, two concepts could be sufficient to understand user flow and make a quick decision.
Constant code refactoring
A situation in which any developer who follows specific style guidelines may find himself. He gets to the point where he realizes that he has written working code, but it does not fully comply with the company’s style guide. For this purpose, he decided to rewrite it.
Then, he realizes that he has missed some small detail of the style guide again and starts again. Again, we need to have clearly defined goals and rules to achieve the ultimate goal. As we already know when we talk about software development, our ultimate goal is always working software. In practice, we could “betray” our principles in cases where they rather hinder the achievement of the specific goal.
Even the Quality Assurance team could find themselves in a Gold plating situation. Developed test cases may involve too many devices. If the team focused on covering all these cases, it would be extremely difficult. The time needed to test a particular change would be enormous.
To do this, you need to clearly define which devices are worth testing. For this, we need to know our audience and establish rules and principles of work that are oriented towards achieving the respective goals.
Another similar type of situation could apply even to ourselves in our role as Software Development Managers. In this type of situation, we may be focusing too much on clarifying the smallest detail in addition to customer requirements.
In this way, we can find ourselves in a situation where the planning time is extremely long, and in reality, the execution part is too easy and fast. To avoid this type of situation, we must be objective and always be oriented to the specific objectives of the project activity, as well as its scope.
Another example of this type of situation is the desire to achieve a software product with zero rate defects. In practice, this is almost impossible, especially when we are talking about a mass product enjoyed by a wide audience. Our users can use the product on a variety of devices, operating systems, browsers, etc. If we aim for a software product with a 0% Defect Rate, we will find ourselves in a situation of gold plating. To do this, we need to be aware of our audience.
To be analytical and to know which are the most common devices, browsers, and operating systems over which our software product is used. In this way, we will focus only on the most important segments and we will not fall into an unrealistic situation.
Another example would be a situation in which instead of using a specific framework, a developer decides to write one himself. In this case, however, writing a framework may seem like an easy and quick task at first, but it can be quite difficult and time-consuming. To avoid this type of situation, we must again have clearly defined rules and procedures, as well as clearly defined and set goals that are tied to specific deadlines.
This type of situation can be a simple task to refactor our software due to the need to change the architecture defined by our software architect. The new architecture can be extremely complex and complex. In practice, it may even require the use of technology by teams with which they have no experience. This type of situation would lead to an extremely long development time, and the ultimate goal may not be clearly defined, which would make it difficult to achieve.
To prevent specific situations, we must clearly define the scope, the objectives of this activity and have clearly defined requirements. In this way, we could design a plan that would lead us to success, rather than falling into a situation where we would simply add a new framework or rewrite a feature without it being clear why.
More examples of gold plating in project teams
Another example of gold plating would be the full development and coverage of absolutely all possible test cases on a software product. Virtually any software product can be used by an extremely large number of users. These users use different devices, operating systems, browsers, etc. Each user can behave quite differently on their own.
If Automation QAs aim to write 100% automation of absolutely all potential cases, then they will find themselves in a situation of gold plating. To prevent this type of situation, we need to know our auditorium well and again clearly define the goals of this type of activity.
Again, another example of gold plating may be a situation in which the UI / UX Designer constantly insists on changes in design implementation. Move one element one pixel to the left, another 2 pixels further down, and so on. When combining this type of situation with the wide range of devices that our users use, it will fall into gold plating. To prevent it, we need to know our audience well and have realistic expectations about the realization and implementation of each design.
Another good example of getting into a gold plating situation could be when working with a client we want to impress at all costs. We can have clearly defined goals to meet even before the deadline. Here, however, we may be too ambitious and seek perfection in our product again. To this end, we have concluded that we have enough time to make a few “quick” and “easy” changes to the latest stable version of our product. In practice, however, after graduating the changes, we may find that we have an extremely high rate defect. Here we can say that this is not a problem for the team, but we still have time until the deadline.
Here, in addition to wanting to fix absolutely all bugs, we can even enter additional change requests. This can become a vicious circle and make it impossible to create a stable release version of our product. To avoid this type of situation we must have a clearly defined scope and requirements. We need to stick to them and have a plan to manage change requests.