1. Define the criteria for the success of the project
At the beginning of the project, ensure that all parties have a common understanding of the success of the project. Often, keeping up with schedules is the only obvious Project success factor, but there are certainly other factors, such as increasing market share, obtaining a specified volume or sales, achieving a specific level of user satisfaction, and eliminating a legacy system with high maintenance requirements.
2. Balance between various requirements
Every project needs to balance its features, people, budget, schedule, and quality goals. We combine each of the above five project aspects into a constraint in which you must operate; You can also define it as the driving force that corresponds to the Project success, or the degree of freedom that leads to Project success. It can be adjusted within a specified range.
3. Define product release criteria
Early in the project, decide what criteria to use to determine if a product is ready for release. You can base your release criteria on how many high-priority defects there are, performance metrics, that a particular feature is fully operational, or something else that indicates that the project has served its purpose. Whatever standard you choose, it should be achievable, measurable, documented, and consistent with the "quality" that the customer refers to.
4. Communication commitment
Although you may inadvertently promise the impossible, don't make a promise that you knowingly can't guarantee. Communicate openly to clients and managers about the actual results. Data from any previous projects will help you make arguments to persuade them, although this doesn't really serve the unreasonable.
5. Write a plan
Some people think that spending time writing plans is better than spending time writing code, but I don't think so. The hard part is not writing the plan, the hard part is doing the plan—thinking, communicating, weighing, communicating, asking questions, and listening. The time you spend analyzing the problem solving will reduce the surprises that the project will bring you later.
6. Break down the task into "small pebbles the size of inches"
The "small cobblestones in the size of inches" are a shrunken milestone. Decomposing large tasks into smaller tasks helps you estimate them more precisely, exposes work activities that you might not otherwise think of, and ensures more precise and granular status tracking.
7. Make a planning worksheet for large tasks
If your group often takes on a specific generic task, you need to develop an activity checklist and planning worksheet for those tasks. Each checklist should include all the steps that might be required for this big task. These checklists and worksheets will help the group member identify and assess the amount of work associated with the big tasks he has to deal with.
8. In the plan, there should be revision work after quality control activities
Almost all quality control activities, such as testing and technical reviews, will find defects or other possibilities for improvement. Your project schedule or work breakdown structure should include modifications after each quality control activity as a separate task. If you don't actually have to make any changes, well, you're already ahead of the plan.
9. Schedule time for Process Improvement
Your team members are already drowning in their current projects, but if you want to take your group to a higher level of software engineering competence, you'll have to invest some time in "process improvement." Set aside some time from your project schedule, because software project activities should include process improvements that will help make your next Project success. Don't devote 100% of the time available to your project members to project tasks and wonder why they don't make any progress in proactively improving.
10. Manage the risks of the Project success
If you don't identify and control risks, then they will control you. Spend some time brainstorming possible risk factors when planning your project, assessing their potential hazards, and deciding how you can mitigate or prevent them.
11. Estimate based on the work schedule rather than the calendar
People usually estimate in terms of calendar time, but I tend to estimate the number of work schedules (in "human hours") associated with a task, and then convert the work schedule into an estimate of calendar time. This conversion is based on how many effective hours I spend on Project success tasks each day, any interruptions or sudden adjustment requests, meetings, and all the other places I might encounter that would take time.
12. Do not schedule more than 80% of the working time for personnel
Keeping track of the average number of hours your team members actually spend each week on project-specific work can be surprising. The overhead of switching tasks associated with many of the activities we are asked to do significantly reduces our productivity. An employee theoretically works 40 hours a week, but don't assume that just because someone is spending 10 hours a week on a particular job, he or she can do 4 of these tasks right away, and if he or she can handle 3 tasks, you're lucky.
13. Put training time into the plan
Determine how much time your team members spend on training each year and subtract it from the time available for team members to work on assigned project tasks. You may have already subtracted vacation time, sick time, and other time from the average, and the same should be done for training time.
14. Record your estimate and how you arrived at it
When you're ready to estimate your work, write them down and document how you accomplished each task. Understanding the assumptions and methods used to create estimates will make them easier to guard and adjust when necessary, and it will help you improve your estimation process.
15. Record the estimate and use the estimation tool
There are plenty of business tools that can help you estimate the entire Project success. Based on their huge database of real-world Project success experience, these tools can give you a possible schedule and staffing scheduling options. They can also help you avoid entering the "impossible zone," where a combination of task volume, group labor, and schedule is unlikely to succeed.
16. Follow the learning curve
If you try a new process, tool, or technology for the first time in a project, you have to bear the cost of reduced productivity in the short term. Don't expect amazing benefits at the first attempt at a new software engineering approach, consider the inevitable learning curve in your schedule.
17. Consider unexpected buffering
Things won't go as accurately as your project plan, so your budget and schedule should include some unexpected buffers behind the main phases to accommodate unforeseen events. Unfortunately, your managers or clients may use these buffers as an excuse for you, rather than wisely acknowledging that this is indeed the case. Point them to unpleasant surprises from previous projects to illustrate your forethought.
18. Record the actual situation and estimates
If you don't record the actual time spent on each task and compare it to your estimates, you will never be able to improve your estimation skills, and your estimates will always be guesses.
19. A task is considered complete only when it is 100% complete
One benefit of using inch-sized pebbles is that you can distinguish between each small task either completed or unfinished. This is much more realistic than estimating what percentage of a large task has been completed at some point. Use clear criteria to determine whether a step is actually completed.
20. Track project status openly and fairly
Create a culture where project members feel safe about accurately reporting the status of the Project success. Strive to keep projects running on accurate, data-based facts, not from misleading optimism born of fear of reporting bad news. Use project status information to take corrective action when necessary and praise when possible.
No comments:
Post a Comment