Every project manager knows that one of the most important aspects of his or her role is to be able to communicate effectively and transparently to all those involved with a project. A project manager must not only be able to convey insightful and meaningful information to project stakeholders, but he or she must also be able to establish a consistent and timely vehicle for communication that can be consumed by all those involved in the project.

How can a project manager establish this vehicle for communication? The answer is simple: by creating and distributing a project status report. This piece of documentation allows project managers to communicate the progress of the project while managing expectations. To ensure that the project stakeholders do not get lost in the details of the status report, I greatly recommend keeping it simple by adhering to the best practices outlined below.

Best Practices for Creating a Status Report

For a status report to measure up to best practices standards, it must be clear and concise. Likewise, it must provide valuable information that clearly illustrates the current state of the project with respect to the project’s scope, schedule, financial position, and risk position.

Divide Sections by Task Type

I’ve found that in order to keep the status report simple and to ensure that it provides enough insight for the project team and sponsors, the project status report should only contain a few sections divided by task type. The types of tasks include completed tasks, current tasks, planned tasks, current issues and risks, and late tasks.

• Completed Tasks: Outline the tasks, deliverables, and milestones that were met during the reporting period.
• Current Tasks: Describe the work that is currently in progress. It is important here to identify work being completed by the project team, as well as information and deliverables that are needed for the project team to effectively begin the planned tasks.
• Planned Tasks: Describe the tasks that are to be completed in the subsequent reporting period according to the project schedule.
• Current Issues and Risks: Identify the issues and risks that affect the project’s scope, schedule, and cost.
• Late Tasks: Identify tasks that are late and include ownership of that task. It is important to acknowledge whether the project team is late or whether the delays are being introduced by factors beyond the control of the project team. The intent is not to place blame, but simply to provide sufficient information to escalate the issue for effective resolution.

Include the Right Amount of Detail

As a project manager, you need to determine the appropriate level of detail to include in the status report. The status report should provide enough detail to be valuable to the project team and stakeholders, but not too much detail that it becomes overwhelming to middle and upper management. Always be aware that the management team has many priorities and is typically impressed by reports that provide information on what is critical to the success of the project. I’ve learned through trial and error that the more efficient you are in presenting the status of the project, the better impression you make.

Align It with the Project Schedule

For a status report to be effective, it must be aligned with the project schedule. We construct our project schedule based on tasks that are no more than 40 hours. Using this rule to dictate task duration, we can make a general assumption that everyone on the project team should have at least one task per week that that should be completed. In addition, this rule of thumb for scheduling allows us to track tasks by resource, which allows us to gauge whether an individual resource is ahead or behind the project schedule. Using this scheduling philosophy, we can easily report the status of tasks that are completed, active, and planned based on the project schedule.

Most Importantly, Keep It Simple

I’ve found that a generally good length for a status report is 1 to 2 pages, ensuring that the highlights of the project are covered. Status reports that are too long will likely not be read completely by all those involved in the project, which will unfortunately waste your efforts. In other words, the key is to keep the status report simple so that all those involved with the project can quickly and easily understand its status.

Why do I aim for simplicity? It is understood that executives are typically on a time crunch and just want a snapshot of the status of the project. The project manager and team, however, usually demand much more detail to fully understand where the project stands. An effective status report should accommodate both of these needs.

To do so, a status report should incorporate an executive summary with a color coded dashboard to visually show the status of the project. Both features give executives a quick update at a glance. Likewise, the status report can easily transition into weekly status meetings with the project team so they have the necessary specifics to discuss the project, make changes, and plan for the next steps.

The Goal of the Status Report

Ultimately, the goal of the project status report is to keep everyone involved and on the same page. This allows the project to proceed as smoothly and efficiently as possible. As a project manager, you will want to make sure there is no confusion about the current status of the project. Likewise, you want to ensure that all of the issues and risks that affect the project’s scope, schedule, and cost are rightfully addressed.

My fifteen+ years of project management experience has taught me a great deal about being an effective and transparent communicator. A good project manager promotes communication by not only understanding his or her project stakeholders, but also by adhering to a proven and consistent methodology when it comes to creating and distributing project status reports. A great project manager, however, knows how to sift through the details to identify and communicate what is most important. In other words, a great project manager knows how to keep it simple.

There seems to be a common problem in the Information Technology industry: it is a great challenge to deliver a web or software development project on time, on budget, and within scope. According to Advanced Project Portfolio Management and the PMO, only 16% of IT projects are able to achieve this status of official project success. We understand that a project must be managed well from beginning to end in order to go above and beyond a client’s expectations and to achieve this status of project success. In order to do this, we believe that you must set proper expectations, focus on project deliverables, communicate early and often, deliver within budget and timeline, and provide service-centered value.

Set Proper Expectations

Before you dive into any project headfirst, it is important to understand what exactly it is your client needs to achieve. After all, you would not build a house without first knowing how many rooms need to be built, where each room needs to sit, and so forth. A web or software development project is no different; it needs to have a detailed blueprint that outlines the end result at the very beginning. A project should not progress past its Discovery phase without completely understanding the end result and what steps will need to be taken to get there. Once it is determined how you will proceed from Point A to Point B, proper project expectations should be set that meet – but mostly exceed – the client’s needs. Likewise, a proper expectation should be realistic, uncompromising of requirements and deliverables, and courteous of a project’s timeline and budget.

Focus on Project Deliverables

Project expectations and deliverables are equally important and should be your focus of every project. When you focus your attention on the expectations of the project and its end result, it is much easier to understand how you will need to get from Point A to Point B. A project that lacks an end result in sight, however, is unlikely to be successful or survive the unexpected. Not only will focusing on the end result allow you to better understand the overall scope of the project and the tasks at hand, but it will also allow you to effectively manage these tasks and ensure that each one is proactively considerate of project scope and budget.

Communicate Early and Often

Communication is the key to exceeding a client’s expectations and delivering a successful end result. A project that lacks timely and routine communication faces the wrath of the unknown, which can be detrimental to the project’s timeline, budget, and end result. You should strive for consistent communication; this means scheduling a certain time and day every week to follow up with your client to discuss a project. This may include the discussion of the project’s status or any performance, testing, or development issues that may negatively impact the delivery of the project. By setting a specific block of time every week, communication allows you to effectively manage the project to ensure that 1) the project is on time, 2) the project is within budget, and 3) the project will deliver the expected end result.

Deliver within Budget and Timeline

To promote client satisfaction, you should aim to deliver an end result that not only saves his or hers time, but money as well. One way to ensure that a project is not exceeding its budget or timeline is to carefully manage change and unplanned activity. It is often said that in project management, the only constant is change. Therefore it is crucial to plan for these unforeseen circumstances during the discovery phase of the project. Change can be a budget and time killer, because it has the unfortunate potential to interrupt other projects and affect the availability of your resources. It is not an easy task to plan for the unknown, but it is extremely important to establish a budget and timeline that is robust, flexible, and accommodating to unplanned activity. This means determining the complexity of project deliverables, determining the greatest constraints (such as time, resources, et cetera), and then planning for these factors while being considerate of deadlines, budgets, and so forth.

Provide Service-Centered Value

At the heart of it all, a client’s expectations are indefinitely exceeded when you are able to provide service to them that not only satisfies, but surprises. We like to call this “Service Surprise”, which basically means that you strive to provide outstanding service that ends your client’s experience on a shockingly positive note. We want our clients to feel as though we are not only delivering an end result, but an end result that is coupled with service-centered value. Because every client is unique in his or her needs, the expectations we want to exceed will therefore be just as unique. To go above and beyond these needs, it is absolutely necessary to truly know your client and what it is they want to achieve. You should continue to manage the project beyond its delivery date by continuously thinking of ways that can provide more value to the client, such as analyzing the effectiveness of a user interface, revisiting a solution to determine if the workflow has improved processes, or keeping up-to-date with the latest technology threats and compliance standards.

We are able to go above and beyond our client’s expectations by abiding to our process and project management methodologies. Our process and project management methodologies ensure that we set proper expectations, focus on project deliverables, communicate early and often, and deliver within budget and timeline throughout the project’s lifecycle. Likewise, we distribute customer satisfaction surveys post-launch in order to obtain valuable information that allows us to improve service-centered value and our internal processes.

If you are stuck in that 84% that cannot deliver projects successfully or if your current processes or project management methodologies are preventing you from going above and beyond your client’s expectations, it might be the time to take a step back to analyze and restructure your framework to a way that will allow you to do so. We hope that these five tips are able to point you in the right direction to help you deliver your next project that achieves the status of project success.

Originally, Steam was used as a way of purchasing and downloading Valve games online, as well as being the epicenter for Valve’s online multiplayer games. Despite starting relatively small and in-house, it was rather obvious just how important Steam was to the gaming community. Now, gamers could download and play the games as opposed to driving to a store to purchase a CD that could very easily be scratched or destroyed. Now, Valve has over 25 million users, over 1,000 titles from various different publishers available for purchase and download, and is estimated to control roughly 70% of the digital distribution market. What also makes Steam special is the ability for one user to download the same game on multiple PCs because each user has their own account name and password that can be accessed anywhere. If you download Half-Life 2 on your home computer, you can access Steam online via your laptop and download Half-Life 2 onto that one, as well. Thus, you don’t have to buy two different copies of Half-Life 2 to install on two different computers; the license-to-use needs only to be bought once.

You don’t have to be a gamer to enjoy the benefits of a Steam-like system. Businesses around the world are using similar systems known as Software as a Service or SaaS. Through an online third-party group (the gaming world equivalent being Steam), the user can access business applications and get software upgrades via the internet. This eliminates the need to equip every device with its own personal license for the software in question, greatly reducing cost. The compact disc also becomes irrelevant, and concerns about damage to the disc are rendered moot. The SaaS model of software access, for the usual monthly fee, is an innovative way for businesses to obtain access to software needed as opposed to licensing every unit in the business for use.

Dvorak Simplified Keyboard

What would happen if, out of nowhere, a company came out with a better MP3 player than Apple? Better storage, more functions, etc. for a better price? Well, it’s happened. Multiple times. Some competing MP3 players offer all of these superiorities, but have failed to achieve the prestige of the Apple iPod due to its seemingly ever-increasing popularity. There are multiple reasons why the iPod has managed to own the competition, including – but not limited to – visual appeal of the product and the huge advantage that Apple has developed in advertising. Even if a product comes out on the market that is proven to be superior to the iPod, there’s a good chance it won’t surpass Apple’s stronghold on the mind of consumers as a whole.

A parallel can be drawn to the existence of a keyboard you might not be familiar with. The modern keyboard layout was created before computers even existed so as to prevent typewriters jamming. While the “QWERTY” layout (the most common modern keyboard) did indeed solve this relative annoyance, there was a concern about the fact that there existed only one vowel on the home row, a feature that still exists today. While effective in its purpose, the need for the layout of QWERTY was rendered moot by computers, machines that don’t have to be concerned with jamming in the same manner of typewriters. However, consumers had gotten extremely comfortable using the QWERTY, and it was perhaps inevitable that electronic keyboards would have the same character layout. Even today, the vast majority of the computer-using population uses a very slight variation of the original QWERTY. Look down at your hands, and there’s an exceedingly good chance that on the home row (middle row of letters), you will find exactly one vowel: “A.” One row up the first six letters will probably be Q-W-E-R-T-Y. The remnant of the typewriter-dominant past still exists.

Despite the fact that QWERTY prevented mechanical jamming on typewriters, there were concerns about the layout of the letters and the strain that was placed on hands during the action of typing. A different keyboard was created in the 1930s – the “DVORAK” – according to what letters were utilized most often and the way that people physically type; the most common characters are more accessible in DVORAK, and the lesser used are placed in more remote areas of the board. A, O, E, U and I are all on the home row, for example. Everything about the DVORAK points to superiority over the QWERTY. But, although the DVORAK is easier to get a hold of now than it was thirty years ago, the QWERTY still has the market by the throat. Yes, it would take you a bit of time to get used to the DVORAK, but carpel tunnel would be much less of a concern for you than it is now. Your efficiency would more than likely see a noticeable increase. But the QWERTY is what we are, as a whole, most comfortable with. The QWERTY, like the iPod, is what we use despite evidence that we should move on to the DVORAK, the usability pioneer in the keyboard world.

Our Interactive Portfolio

We at Galvin Technologies like to think of ourselves as the DVORAK of website usability. It’d be easy for us to go the same route as everybody else and design websites according to the QWERTY layout the industry has provided us, but we choose to take a step or two out of the box. We don’t want to completely buck the trend, and do pay close attention to the requirements of business models, but try to take into effect usability aspects: the QWERTY vs. the DVORAK. Just as the DVORAK was created with the user in mind, we design websites with the users in mind. The QWERTY was useful when it was necessary, but it’s time to move on; sometimes it’s better to come up with something new and a little different, more user-friendly, than continue to follow a trend of blatant usability inferiority.

Ok. You have decided to make a monumental decision: you are going to hire an architectural company to build a new house for you. After months and months and what has to equal hundreds of thousands of dollars, you drive to your new home, walk in and…realize things aren’t quite right. You flip the switch for the garbage disposal and the upstairs toilet flushes. When the dryer runs, the air temperature drops thirty degrees. This is not what you had in mind. You have wasted lots of time and lots of money on a product that, in the end, was nowhere near what you wanted.

This is a legitimate concern in the software engineering and development world as well as any other type of construction. It’s easy to just build a house or just design a car if a customer asks you to, but there is so much room for error and disappointment, cost in both time and money, that we choose a little more intimate of a route. Not only do we develop websites for our clients, but we also develop business systems. To do this in at our most efficient level, we go over the functional requirements of the system with the client and follow that up with use cases.

Some sites can be basic, flat html pages, where the user can visit multiple pages via links and learn about the company, the products the company sells, and navigate pages without really doing anything other than that navigation. For example, a florist shop – let’s call it Fiona’s Flowers, based out of Tampa – has a website with a few pages that give the company’s bio, some contact information, some pictures and a list of various plants and boutiques one can purchase at the shop. All in all, it’s not much more than an online Power Point presentation that the user navigates. One can’t buy anything online, nor can one compare prices to other companies when Fiona boasts that her prices are the best in the area.

Now let’s backtrack and say Fiona hasn’t had this business designed yet, much less a website, but she knows what she wants there. She comes to us and says, “Hey, I’m going to be building a floral company. I have nothing except my idea and how I want it to work.” It is then our job to define the functional requirements – what Fiona’s system has to do – for the business system and the company. She has to have customer’s able to purchase online, has to have a shipping service and options for shipping, has to be able to compare prices for each and every plant she sells with the competitive market, etc. We end up with a laundry list of the client’s desired functions for their system because we want to design a complete system for you. Software engineering is, in essence, no different than engineering a car; what are the pieces and parts I have to build to make all this happen?

We’ve listed what the customer wants and documented what this product should do, and now we have a laundry list for system purposes – the functional requirements. Once we have that, we lay it all out into modules, creating a model for everything from application to the storage database. After looking at this list and modules, each building block in the application model, we start creating use cases.

Let’s look at an insurance company, for example. One objective for a use case, the process associated with it, might be creating a quote and saving it to the database for future viewing. The functional requirements are the ability to print the quote, generate a pdf file for emailing, etc. A use case for this quote creation would documents the flow of a user’s steps to creating a quote, from interface appearance, generating a quote number, attributes of the policies available and coverage, and so on and so forth. The use case basically walks through the steps of how a user uses the web page of the insurance company and its components.

Also documented are the specific business rules applied. The customer enters information on the screen  and clicks “save.” The next step would be applying a business rule according to what is laid out in the use case – what has to happen. A quote number needs to be created. What numbers are generated? How are they generated? These are business rules that have to be applied to meet the functional requirements discussed earlier. What happens if the driver’s license isn’t validated or wrong information is entered? What happens if a license number has expired? These are logical business outcomes that need to be very clearly laid out. If a user wants to take a policy on Dodge Viper and the business isn’t willing or able to take on that car value, what is the process that needs to occur that sends a message of refusal? The response is documented in the use case.

---

We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone.

---

Use cases are important because it forces both our client and us to agree on everything that is going to happen. We get sign off on everything before we sit down and design the product. We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone. It’s not only a system for agreement, but it gives the developer, who doesn’t make much contact with the client until the use case is developed, a very specific idea of what they’re going to be building and how to go about doing it. As the blocks agreed upon in the functional requirements are built, what we had previously discussed and agreed upon is enforced.

So, back to the house example from the very beginning. If we built houses, we would sit down with you and discuss – and agree upon – the functions for everything in the house. This switch will turn on the garbage disposal, this will turn up the heat, and this will lock the door. There’s no room for confusion or the possibility of a devastating mistake either on your expectations or our construction. The whole purpose is to get confirmation that what we’re developing is in essence what you need before the product is created. It saves you money. It makes us efficient. And it makes the products stronger, better, and faster.