Project Communication Series: The Project Status Report

Posted by Brad Egeland

status report1 300x241 Project Communication Series: The Project Status ReportI’d like to go through a communication series and cover every aspect of what’s involved for effective communication on the project with the team and the customer.  Requirements may be the lifeblood of the project, but communication is the beating heart and without proper, effective, and efficient communication no project can succeed.  And that all starts with the project manager.

In the first segment, we’ll start looking at the project status report.  Because it is something that is produced weekly, contains up to date status, and drives the weekly status call with the team and customer (at least in my methodology it does!), it is one of the most critical pieces to your project management puzzle.  Skipping it or slacking on its information is really not an option.

If you share my belief that the project status report should drive the weekly status call, then all relevant project status information should be included.  In fact, look at the status report as something that you – the project manager – could produce and give to just about anyone and they could then drive the project status meeting.  This serves two purposes:

  • It allows you to miss a meeting if you have an emergency or another project needs your attention
  • It gives you something that you can hand to your senior leadership at any given time and say “here is the current status (within days) of ‘x’ project”

Read more »

Five Signs You’re Not Cut Out to be a Project Management Consultant

Posted by Brad Egeland

Consulting, in general, is not for everyone.  Likewise, consulting it the field of projectConsultantServices2 300x300 Five Signs Youre Not Cut Out to be a Project Management Consultantmanagement is not something everyone is ready to handle.  Even if you’re a 15-year veteran of project management, that doesn’t mean you have the tools, the stability, and the make-up to go out on a limb as a consultant in your given field.

We all know that project managers have a few skills and characteristics that they must have to some degree to be successful:

  • Leadership
  • Communication
  • Organization
  • Confidence, etc.

The list can go on for quite awhile.  Those are still necessary for the project management consultant, but let’s look at five key signs which can point to individual characteristics that should be present to help enable you to be a successful consulting project manager.  If you don’t have them, it’s probably not a field that you should be in.

Read more »

Is a Statement of Work Really Important?

Posted by Brad Egeland

sow Is a Statement of Work Really Important?How important is one document to a project?  You know they drill… if you were stuck on a desert island and only had one project document to run with, what would it be?  Sure, requirements are critical.  I’ve always said that successfully documenting requirements on the project is one of the most critical things you can do.  But how do you get there?

In my opinion, the Statement of Work, or SOW, is probably the most critical document you can start off with on a project.  It gives you everything you need to start building your project from – of course that’s only if it exists and it’s done right.

Which brings me to my next question.  How big or small does a project need to be to warrant an SOW?  Is there a dollar amount below which an SOW is overkill?  Or is there a minimum project duration below which a SOW would be an extravagance?  An unnecessary luxury?  My answer here is a definite no.

If a project is handed to you and there’s nothing but some notes on a paper, my recommendation is to stop, refuse to move forward, and request a formal statement of work.  If one can not be produced, then I highly recommend building tasks into the front end of the schedule to incorporate sitting down with the project sponsor and creating at least a minimal statement of work document.  What you’ll gain from this type of planning up front in the project is invaluable.

Read more »

Ten Characteristics of Successful Project Teams – Part 5

Posted by Brad Egeland

In Part 4 of this series we examined items six and seven of ten characteristics ofpositive team 294x300 Ten Characteristics of Successful Project Teams   Part 5successful project teams: valued diversity and managed conflict.  Here is the full list of the ten main characteristics of successful project teams that we will be examining in this series:

  • Clearly defined goals
  • Clearly defined roles
  • Open and clear communication
  • Effective decision making
  • Balanced participation
  • Valued diversity
  • Managed conflict
  • Positive atmosphere
  • Cooperative relationships
  • Participative leadership

For Part 5 of this series, we’ll examine item eight in more detail: a positive team atmosphere.

Positive team atmosphere

To be truly successful, a team must have a climate of trust and openness, that is, a positive atmosphere. A positive atmosphere indicates that members of the team are committed and involved. It means that people are comfortable enough with one another to be creative, take risks, and make mistakes. It also means that you may hear plenty of laughter, and research shows that people who are enjoying themselves are more productive than those who dislike what they are doing.

Read more »

Considering a Phased Project Delivery

Posted by Brad Egeland

phased delivery2 300x225 Considering a Phased Project DeliveryAs we’re delivering on a project for a customer, there may be numerous reasons why the project would be best moved to a phased project delivery situation.  The most common is the result of numerous requirements changes or change requests initiated by the customer while initial functionality is still badly needed by a specific date.  In a situation such as this, where the project cannot deliver the complete project or product by the deadline, there is still the possibility that it might deliver some useful part of it by the original promised date or close to it.

Technical projects composed of several subsystems, for example, often implement one subsystem at a time. Tenants can move into some floors in a new office building while there is active construction on other floors, and sections of a new freeway are opened as they are completed rather than waiting for the entire freeway to be complete.

Phased delivery has several benefits:

  • Something useful is delivered as soon as possible – and in the case of many changes affecting the project, some critical base functionality may still be deliverable by the original agreed upon date.
  • Often, as in the case of information systems, phased delivery is actually preferred because the changes introduced by the new system happen a little at a time. This longer time frame can reduce the negative impacts to ongoing business operations.
  • Feedback on the delivered product is used to improve the products still in development.
  • By delivering over a longer period, the size of the project team can be reduced; a smaller team can lead to lower communication and coordination costs. In addition, because the people are working for a longer time on the project, project-specific expertise grows. These factors should lead to increased productivity in subsequent project phases and to an overall lower cost for the project.
  • Phased delivery allows for phased payment. By spreading the cost of the project over a longer time, a larger budget might be more feasible for the customer.

Modularized products, whose components can operate independently, can be delivered in phases. To determine how to phase a project or product delivery, you need to look for the core functionality—the part of the project that the other pieces rely on—and implement that first. The same criteria may be used in identifying the second and third most important components. When multiple components are equally good candidates, they can be prioritized according to business requirements.

Trade-off: Phased implementation increases functionality at the expense of schedule. If the approach requires old methods to run concurrently with new methods, it could also temporarily lead to higher operating costs.

Impact on risk: When components of a solution are delivered over time, the connections, or interfaces, become high risk. For technical solutions, that could mean corrupted data.

Information for this article was derived in part from Eric Verzuh’s book “The Portable MBA in Project Management.”