The famous management master Paul Grace asserted: "In the 21st century society, everything is a project, and everything will become a project".
In fact, as Paul Grace puts it, project management has become a tool for many businesses to survive in an era of rapid change.
But the involvement of many stakeholders in the implementation of a project often complicates things too much, which is a common reason why most software projects fail.
In general, project team members certainly have the ability to set project goals and complete them on time and in good quality, but many parties involved believe that project goals can be achieved in just a few simple, unrealistic steps.
They find the final solution to achieve the project's goals easy, even if the project is very complex.
In fact, the project stakeholders should not see the software project as a unified, huge and rigid monster, but should let the information technology team build the project into an onion, and each long layer means a mature point.
There is no other room for choice in the real world, no matter how well-developed the project requirements are, there will certainly be changes, and if your software is not flexible enough to adapt quickly to changing requirements, the project is likely to be doomed to failure before it starts.
In order to keep the project as simple as possible, it is especially important to do the following points -
(1) Keep the requirements simple
Requirements analysts often confuse a solution they have in mind with the actual customer's needs based on business needs.
While the actual requirements may be very simple, a lack of real understanding between the requirements analyst and the developer can lead to a lack of communication between the two sides.
In general, the requirements analyst should write out the requirements with a simple tree diagram, the fundamental requirements are the simple goals of the overall project, and the child requirements of the small branches and leaves are divided into branches and leaves representing the parent needs.
This process is repeated throughout the diagram until each requirement is clear and clear, and as soon as the requirements of a small subset are identified, the development work can begin.
(2) Follow the agile development process
Once the requirements for a small set have been identified, the development team can immediately begin to prototype.
As long as the prototype is available, stakeholders can test and provide feedback that ensures the accuracy of the information and identifies differences in communications that may arise when requirements are passed from the actual customer to the project team through the requirements analyst.
Giving customers a look at the prototype can also help check that the solution the developer envisions is consistent with what the customer envisioned.
If there are differences, those differences create new requirements, so the developer redoes the prototype and repeats the cycle over and over again, each as short as possible, usually no more than two or three weeks.
A small set of defining requirements, creating a prototype based on the stated requirements, and then getting feedback, this cycle ensures that all stakeholders in the project always agree and everyone is satisfied with the progress, as long as these simple tips are carefully followed, each software project can eventually be a complete success, which means that the customer is satisfied and the software is practical, and the effective business functions provided by the software are exactly in line with the original purpose.
Well, the above is the main content of today's sharing, I hope to be able to help you in project management, if you have any questions about project management, you can also leave your questions in the comment area to exchange and discuss, see you in the next issue Oh ~
Note: The pictures in this article come from the Internet, if there is any infringement, please contact to delete