Bad Planning

The organization of project work does not begin and end with the Work Breakdown Structure or the project schedule. A good project plan is similar to a good battle plan: they are both possible to execute. A good battle plan may not be easy to execute, in fact the best ones rarely are, but they are designed to take advantage of the strengths of the force that must execute them. A good project plan should also take advantage of the strengths of the project team.

Some common causes of bad project planning are:

• Not tailoring the plan to fit the strengths of the team
• Not choosing the right software development methodology for the project
• Missing or improperly captured deliverables
• Milestones that cannot be met by the team

These can all be avoided with some careful analysis of the project and its resources before the plan is finalized. Each of the causes listed above can be avoided. Here are some strategies for avoiding them.

Avoidance Strategies

Assess the skill sets on your team. Don’t just assess their inventory of skills; assess their status with that skill. Is the JEEE programmer a senior, intermediate, or junior programmer? You need to take skill levels into account when calculating the effort required for programming. Use a weighting tool to do your effort estimations. For example, if a function would take a senior programmer 20 hours to program, you might allow a junior programmer a skill factor of 2 for the same function (20 hours x 2 = 40 hours). The factor you should choose will depend on the estimate and the tools you are working with. In some cases, you may need to adjust the effort estimates downward for the senior programmer.

You also may need to work some coaching or mentoring into your plan if you have junior programmers on your team. Be careful not to overload the team with too many junior programmers; if the junior programmers outnumber the senior and intermediate programmers, you may not be able to execute.

Evaluate the amount of work required and the total number of resource hours available to ensure there are enough resources to perform the work required. If there are not enough resources you have two remedies: more resources or productivity enhancing tools. More resources can be addressed in one of two ways: more resources or replacing junior resources with senior resources. Productivity enhancement tools can be used to increase the capacity of existing resources. For example, if your QA team cannot be increased you could purchase automated test tools to eliminate manual test effort. Be certain you plan for training and any up front overhead that implementing the tool entails.

Don’t just examine technical skills when you are forming your team. Soft skills can play an important role in your team’s productivity and if you don’t acknowledge this in the planning phase, you will pay the price during execution. The most important soft skill to your project team will be the ability to work as a member of a team. That means the ability to extend and accept help. You can probe for this skill during interviews by noting how often accomplishments are described using the pronoun "I” versus "We”. You may also want to ask questions that probe the depth of experience the interviewee has with team work. A software development project that is loaded with senior programmers who have always been "individual contributors” will be very problematic for their project manager. There are some things you can do with your plan to address a lack of team work experience. You can take advantage of specialized training which builds productive teams. You can plan team building activities. You can also give your individual contributors work which does not require a great degree of integration.

Choosing the right software methodology is almost as important as tailoring the plan to fit team strengths. Choosing the right methodology requires you to select a methodology that will be the most effective for the project you are undertaking, and is also a good fit for your team. You may have a project that is ideally suited to the SCRUM development methodology but if your team only has experience with the Waterfall methodology, don’t expect them to be able to produce using the new method. There are some strategies you can use to address this gap. Although nothing can replace experience when it comes to development methods, you can train the team in the new methodology, just be sure you allow enough time for the training and subsequent learning curve. You can also create your own hybrid methods that marry the methods your project needs with the environment your team is used to. For example, use Waterfall methods within each iteration of an iterative project when the project needs to build a system incrementally but the team is accustomed to the Waterfall method.

Your project schedule, a derivative of your Work Breakdown Structure (WBS), is your project bible. If work required for a deliverable is not in the schedule, the deliverable won’t be produced. The work comes from 2 main sources: your Scope Statement, and your Statement of Work (SOW). You may only have a Scope Statement to work from, depending upon the size, complexity, and customer for your project. You will have to do the analysis normally done to create the SOW, with the work breakdown analysis, if you don’t plan on creating an SOW. Remember that an SOW will provide the project manager with benefits even if the project’s customers don’t require you to produce one.

The composition of your project team, the tools available to the project, the software methodology, and any constraints must be accounted for when producing the SOW. You will need to identify any work required to provide training to the team, and plan it. You will also need to plan procurement activities to acquire any tools, software, or hardware required. Seek out Subject Matter Experts (SMEs) to provide guidance for the deliverables and deadlines in your SOW. Other project managers are a valuable resource, especially if they have had experience in the type of project you are undertaking. Their experience may extend to all aspects of the project, or it may be limited to projects using the same software development methodology in yours, or projects using similar tools. Ask the experienced project manager to review your SOW to ensure that it is feasible and reasonable.

You should also ask other SMEs on your team for input. SMEs in the area of business analysis, development, and Quality Assurance (QA) testing can help you verify the project elements that fall within their area of expertise.