The Template Collective Blog

Project management templates… and more

Monthly Archives: June 2015


Determine Whether Full-Time or Contract Resources are Appropriate

Perhaps the place to start is to understand whether there are employees available in the time-frame needed for your project. It usually doesn’t make sense to hire contract people when you have employees that are available and otherwise would have nothing to do (assuming the employees have “close-enough” skills).

Let’s assume that you do not have current employees available to staff your new project. Let’s also say you work for an organization that is open to utilizing contractors or hiring employees depending on the needs of the specific project. Let’s look at some of the criteria that you can use to make the hiring decision.

    • Urgency. If you need to get started very quickly, you may need to hire contractors. In most organizations you can put a call out to the local contract companies and be interviewing people in a couple days. Most organizations can’t (and don’t want to) hire employees that quickly.
  • Length of the need. If you need a resource for a short, finite duration, then a contractor may be the way to go. You can bring them in for a short contract and then release them when the work is done. If you have a full-time, long-term need, an employee would make more sense.
  • Strategic vs. non-strategic work. Many companies identify certain types of work to be more strategic that other types. For instance, many companies chose to staff the senior project positions, like the project manager, with employees, and are more willing to use contract labor to assist with project team members.
  • Skills and knowledge needed. Many companies make decisions about staff based on the type of skills needed. For instance, if you are moving into a new technology or new equipment, you may hire contractors that already have the expertise. If the skill is needed long-term you might want to transition in some employees so that they can learn the new skills before the contract staff leave.


  • Confidentiality. Many companies chose to staff positions with employees if the project team will handle confidential or proprietary information. There is a sense that the information might not be confidential once the contractor leaves the company.
  • Cost. With a contractor, you typically pay a higher hourly rate, but only for the length of time the contractor is needed. Employees may cost less in the short-term, but you are taking on a long-term cost commitment.

If you look at the decision criteria above, you can see that much of the answer for using employees of contractors comes down to risk. If a project is short, it might be risky to hire an employee since you may not be sure if you can keep the employee busy long term. If the project involves core skills to your organization, confidential information, or is strategic to your business, it may be too risky to hire a contactor.

Organizations tend to keep a leaner staff of core employees these days. The core staff stays relatively constant from year to year, while increases in workloads are staffed through contract resources.


project solution

Ways to Judge Project Success

Projects that nail the triple constraint are not necessarily a success. Conversely, projects may be deemed successful without satisfying the triple constraint. Ask yourself the following four questions to determine whether or not your project can rightly be judged a success.

#1 – Is the Client Happy?

One of the best indicators of success on a project is when a client is happy with the results, whether that client is internal or external to the organization. “But,” you may ask, “what if the project went over budget and we weren’t able to bring it in for the amount the client requested?” When that happens, it doesn’t mean the project failed. For example, I just had my house painted. Both the cost of paint and labor ran over budget. I’m still extremely pleased with the results and deemed the project a success.

#2 – Are You Looking Forward to Working Together on the Next Project?

Projects can get a little rough and tumble as people with different personalities, skill sets, expectations, and experience come together to complete a project. There are going to be moments of great exhilaration parallel to instances of deep despair. Does the sum total of these experiences net out to a positive vibe? If you, the team, and your client are able to see the project in your rearview mirror and stay excited about working on the next one – then it indicates that your project was a success.

#3 – Did You Get Paid for the Project?

For external projects, payment is a huge indicator that a project was successful. Let’s face it; if you or your company doesn’t get paid for a project for any number of reasons, it would be considered a huge failure. The client may not be satisfied with the project results (see #1 above). You need to be diligent to ensure this doesn’t happen to you!

#4 – Were the Desired Outcomes Met?

A definition of project success is found in the objectives listed at the beginning of the project. They provide guidance for judging when a project can be considered complete. The list will detail the end state of the project, i.e.,

The time tracking software will be deployed to all employees across three company locations. All employees will be trained on the software and have a Quick Start Guide to assist. Additionally, the Call Center will be brought up to speed to handle any support issues.

If the results of the project match the desired outcomes, then it can be considered a success.

There’s more to judging project success than just being on time, within budget, and in scope. The triple constraint is the foundation of project management, but not the end-all, be-all of project success. Ask yourself these four questions and you’ll find your projects reaching an even greater degree of success!


Characteristics of Agile Iterations

Most people understand that the days of the five-year, monolithic project are over – and have been for some time. The better approach is to break large projects into a set of smaller, easier to manage projects. Short projects are easier to manage than large projects. There are fewer things that can go wrong, fewer people involved, less time for scope changes, etc.

Characteristics of Agile Iterations

The Agile model takes this to an extreme by stating that even the days of the six-month development cycle is over, as is the three-month cycle and maybe even the one-month cycle. Partial solutions should be up and running in a very short time, with very short iterative cycles designed to deliver working code that is built up to a final solution.

Implement Complete Functionality

Agile iterations implement complete functionality for a set of selected customer requirements. This includes the complete mini-lifecycle of analysis, design, construct, test and implementation. The selected functionality within the iteration is not worked on simultaneously. Instead new functionality is worked on as team members are available, meaning at any given time there may be one or more requirements independently going through analysis, design, construct, test and implementation.

Implement Holistically

Each iteration is compressed to a few weeks or even a few days. Short iterations are the result of a holistic set of characteristics of the Agile model. It is not easy to deliver in very short cycles if you pick some of the Agile techniques and ignore others. For example, one of these characteristics of an Agile project is that the product owner is integrally involved in the project and is empowered to make decisions in short timeframes. Obviously you cannot run two week iterations if your product owner consistently takes a week or longer to answer questions and make decisions.

Create Short Iterations

Each team should determine the length of an iteration for its specific project. Shorter iterations are generally better than longer iterations, and 30 days is probably the longest that you want an iteration to last. Shorter iterations tend to squeeze out inefficiencies and overhead processes. For example, you may choose a 30-day iteration because you have a one week approval process at the end of the iteration. If you force the iteration down to two weeks, it will also force this review process to get shorter as well.

Keep Iterations Consistent

It is important that each iteration stay the same length so that your team can develop a steady rhythm of work. If you chose a 30 day iteration, for instance, you need to make sure that each iteration is delivered in exactly 30 days. You don’t want some sprints taking 35, 40 or 50 days. If that happens the Agile discipline breaks down and the project moves more toward a traditional model.