You used a respectable consulting company to carry out a large project. You prepared a request for proposals to conclude a contract, carefully examined all the answers, listened intently to the company's oral presentation, and finally discussed and signed a well-written work report.
But you shouldn't stop there!
A well-written job report can set you on the right path, but it doesn't deliver success. In reality, the project manager who is supposed to do the project may not actually be the one who wrote the report.
As a leader, you can and should do something to help guide your projects from signing a contract to execution. A meticulous review of the project plan is one way to accomplish this transition, and it's actually one avoidable but surefire way to identify problems early on. Therefore, you should take the time to review the project plan and the task of some issues. Here's what you should pay attention to:
1. The analysis, preparation and documentation of assignments should be clearly defined.
Many software development projects require extensive analysis and planning before development begins, until all requirements are 100 percent defined. For example, make sure that you have defined all the tasks to analyze the process, determine the requirement, and all related areas. Make sure you have the opportunity to discuss security, response times, user roles, data conversion, delays, reports, test preparation (rather than just performing testing), etc.
When assessing the level of detail, many managers use the "40 hours" rule, which is that all tasks must be completed within 40 hours. But it will be much more effective to include preparation and documentation tasks. For example, see how this project plan describes the steps to document the requirements:
- Collection of claims, invoices for payment (40 hours)
- Claims collection, cash use (40 hours)
- Collection of requirements, invoices to receive (40 hours)
- Completion and signing of claims (40 hours)
The project team has two people on a permanent basis whose task is to document the requirements, so they should be able to complete this segment within two weeks.
But you should consider the plan as follows:
- Eight meetings - bills payable, 2 hours each (16 hours)
- Preparation - one hour per meeting (8 hours)
- Documentation of results - four hours per meeting (32 hours)
- Repeat pattern for other functional areas
The new plan corresponds to 56 hours of effort, instead of 40 - in the original. If this pattern is sustainable, then knowing this, you can start with 40 percent over budget. By rewriting the plan, team members will see that two weeks is not enough to complete this, especially since the meetings will be held on schedule. And if they can't provide you with that level of detail, then they're not familiar enough with the project.
2. Distribution should be done wisely.
Check the distribution of forces - if the project corresponds to the waterfall style, then calculate the percentage of hours spent at each stage (analysis, design, assembly, testing and implementation). If the style of the project is "prototype", then you should count the number of hours spent to reach the first and each subsequent checkpoint. Do not take into account the tasks of project management. If the requirements have already been discussed and defined, then you should not accept the plan if 30% of the hours are devoted to analysis. And if the project is only at an early stage (and much is determined during the course of the project), then you should not approve the plan with 5% of the time devoted to the analysis.
3. Checkpoints should be installed every 30 days or less.
One of the easiest and most effective ways to manage multi-month projects is to use well-defined checkpoints. Require a formal presentation of the development at each checkpoint, schedule the process of reviewing and reviewing the prototype from the first iteration. For quick, specialized development projects, checkpoints may be obvious and an early review of them may indicate failure or success. For new, more complex projects (such as enterprise intelligence or data management), you should make sure that your consultants have the necessary experience to identify practical checkpoints.
4. Dependence on circumstances should be calculated.
Uncertainty should have an "emergency exit" for uncertain problems or unplanned work, and it should also be taken into account in almost every project. If the project manager tells you that the situation does not require a survey for unplanned tasks, then his inexperience in large projects is obvious. Once a specialized project has been developed and its plan has been carefully prepared, you should allocate 10-15 percent to unplanned tasks, and maybe more - it all depends on the organization and maturity of the project.
5. Project management steps should be defined, not proposed.
Project management is a sequence of tasks, and they should all be included in the plan. Activities such as document review, presentation preparation, and status reports should be easily identifiable and counted. Don't adopt a plan that includes only technical tasks and only one person acts as a project manager.
If you follow these rules, then the project should develop without interference. And since the plan clearly describes the tasks that need to be solved, you can help in solving them before everything gets out of control.
In addition
Signing a contract is not everything. You should follow these steps to assist consultants in their in-process analysis and less time to learn logistics.
Set up a kick-off meeting – explain the goals and roles to everyone interested in the project.
Be frank - clearly argue your arguments if there is a need for outside help.
Use a schedule plan. Don't let consultants schedule meetings.
Discuss between phases – Help consultants focus on what's useful for your development environment.
Help with the format – if your organization has standards for providing documents, recommendations and calculating ROI, then you should provide them to consultants in advance.
No comments:
Post a Comment