More Ways to Separate your Project into Manageable Chunks

In Part 1 of my article “Split It Out,” we looked at ways to separate projects task into smaller parts or pieces that are more controllable. Let’s look together at a few more areas that can be split out for project success!

Partnering it out

In today’s highly sophisticated industrial environment, it is often best to partner with other organizations that can perform special segments better (for example, subject matter experts), rather than doing it all in-house. Often called “outsourcing,” these types of partnerships are increasingly employed in current projects. A PM partners with third party vendors and obtains buy-in from the various performing organizations. It is important to remember that most outsourcers report to the PM, and it is vital for the PM to document everything they have accomplished for historical/reusable purposes, before they “hit the road.” In addition, even though the project’s sponsor might hold the purse strings, the sponsor, at times, needs to be partnered with the PM by providing him or her with continued support and involvement.

Phasing it out

Every project should be broken down into at least four phases: Initiation, Planning, Execution, and Closure. There are many IT resources that incorporate these phases and related tasks into a project template.

• The Initiation phase is usually the short piece of work that includes preparing the business case, project charter, preliminary scope statement, and assembly of the team.
• The Planning phase is about finalizing the scope statement and creating a WBS hierarchical structure with its level of WPs, which include summary tasks, milestones, cost planning, communication planning, risk management, and procurement processes. Always look for WPs that don’t support the scope statement and for WPs missing from the scope that should be included. Generally, the more time you spend on planning to get it right the first time, the less time you will spend on execution.
• The Execution phase is where the bulk of the work is done. This includes the big task of monitoring and controlling your work to make sure you stay on track, and managing risks, issues, and changes. The more tools (for example, Microsoft Project) and techniques PMs have at their disposal, the easier this phase will be to influence the outcome of their project in a positive manner.
• The Closure phase is similar to the initiation phase. You want to keep it short and simple. Closure activity should primarily be that of getting acceptance sign-off from the client that the project was successfully completed. There may be other closing processes like tying up loose ends, capturing lessons learned for future projects, and thanking the team for a job well done.

Programing it out

If you have a software development project, the first step should be deciding which methodology model to use because this will have a profound impact on controlling the schedules, costs, and the quality of the project. Choosing a model depends on many factors like project size/complexity, need for user/customer involvement during development, available tools, and staffing profiles. Historically, most software projects used the waterfall model for scheduling projects because it was the first or earliest process model to be introduced. This process is called the linear-sequential life cycle, which means any phase of the development process begins only when the previous phase is completed. This is also a predictive life cycle model because the scope, schedule, and cost can be predicted accurately. Generally, this is well suited for medium to large projects with well-defined requirements.

In contrast to predictive models, there are adaptive life cycle models where the software requirements are not clearly defined, and therefore, the software is developed using a less structured approach. An adaptive approach is either iterative or incremental. An iterative approach starts with a simple implementation on a small set of software requirements with iteratively enhanced growing versions building upon one another until the system is completed. Incremental means each build is a step beyond the previous one l in terms of features, and that the final build holds all the features required by the customer. The fastest growing adaptive model being used today is Agile, which is really a combination of the iterative and incremental approaches. More and more organizations are using a hybrid model (waterfall/Agile) for certain projects, and future versions of Microsoft Project will include more Agile features.

Resourcing it out

A big part of resource planning includes resource leveling and reallocation, which is one of the hardest things for a PM to do. In essence, a PM needs to make sure to have the right resources at the right time to successfully complete the project. The main purpose of resource leveling is to avoid resource conflicts, so you can have a smoother distribution of resource usage. For example, you may have a person scheduled to work eight hours on a critical task and another eight hours on a non-critical task on the same day. Obviously this person can’t work on both tasks at the same time and you would want the person to work on the critical task first, so the planned finished date for the project is not altered. This means the non-critical task should be delayed to a different date or different dates (for example, 4 hours/day). The following are some other work arounds for resource leveling and reallocation.

• Rearrange task sequences to eliminate resource conflicts without changing the project’s end date. This is usually the easiest and the first thing you want to try doing.
• Work overtime. Remember this could “burn” people out and/or add additional costs.
• Add more resources, which will add additional costs to the project.
• Decrease the project scope. This should be done during project initiation and not later.
• Increase the skill level of the team with appropriate training before the project starts.

Microsoft Project can automatically level resources. This usually pushes out the project’s completion date, which some stakeholders do not like. A skilled PM must act like a surgeon and make resource level adjustments to the project plan to meet the project’s completion date. Microsoft Project has many tools for the PM to tweak a task’s resources allow for the correction of over allocations.

Risking it out

A risk management process identifies tools and techniques to aid in minimizing uncertainty through understanding, assessing, and managing the uncertainty that is inherent in projects. This will aid the PM in maximizing the probability of a predictable outcome. It is important for the PM to categorize risks using headings such as technical, commercial, management, resources, and external. The next step is risk response planning to develop action plan(s) on how the risk can be reduced or mitigated. There are currently four standard risk strategies: accept risk, avoid risk, mitigate risk, and transfer risk (could include sharing a risk with a third party).

Large projects will invariably discover new risks during the execution phase. This should be planned for by setting up a Risk (or Contingency) Reserve, through which approved funds from the total base budget can be moved into the WBS structure as a normal work activity. To summarize, the more time an organization spends on risk management in the beginning of a project, the less they would spend on issues and changes during the execution of the same project.

Scoping it out

One of the most difficult things to do is define the scope of a project. Ideally, you would like to keep the scope small to save time and money, but this doesn’t always happen. A project with a large scope can be difficult to manage, but scope change can also have a similar effect. The purpose of scope management is to help ensure that all the required work is covered and that only work that relates to the scope is completed. In short, the scope statement should include what work is included and what work is not included, which will help to reduce “scope creep.” The boundary lines should include project constraints (for example, limitations on resources) and requirements that must be met (for example, ordered equipment must be received by a certain date).

When a PM receives a request for a scope change, he or she must be diligent in knowing that the client isn’t always right, but could be. Bottom line, make sure there is adequate justification for the change. Otherwise, unnecessary changes can turn a good project into a troubled one! Large projects will invariably have “scope creep,” and it needs to be planned for by setting up a scope reserve. Approved funds from this reserve can be moved into the project’s WBS as normal work activity, which would become part of the total base budget.

 “What if” it out

Playing the “what if” game is useful analysis to compare variations (tasks and/or resources) between the current version of a project plan and an earlier version of the same plan. A comparison of this type can be very useful for developing different alternatives for a new project that could possibly save time and money and make stakeholders happier. Furthermore, this analysis can be very handy when analyzing scope changes in a project. In performing what if analysis, always remember to keep a backup copy in case you need to return to your original base.

Microsoft Project has a “what if utility” in which you open the original file first and then the updated file. After this, choose Report – Compare Projects. In the Task Table drop-down list, choose the table that contains the fields you want to compare (Note: the default is “Entry” meaning that it will show all the fields in your plan). Do the same for the Resource Table drop-down list and when done, click OK. Then, the scrambling screen magic starts! The Comparison Report will be shown on the top half of the main project window, the current version appears at the bottom left, and the updated version appears at the bottom right. A legend on the top left hand side of the Comparison Report identifies the symbols it uses. For example, tasks that appear “only” in the current project include a “+” sign, and tasks that appear “only” in the previous version include a “–” sign to indicate that they have been removed in the current version. Note that you can save the Comparison Report if you want.

Summary

As I said previously, following these tips for breaking things down should improve any PMs credibility, performance, and chances of success. A good guideline is to always think in detail! It is also helpful to brainstorm with the people involved in your project by “thinking outside the box” and by reviewing past lessons learned to help eliminate any negative effects when developing your project plan. This topic has been all about planning. Spending more time on planning should lead to less time and effort on your project’s execution; therefore, reducing the total cost. The best PMs know and practice these important processes!