Project Communication Series: Project Schedule
Posted by Brad Egeland
With the project schedule being so important to tracking the overall status of the project, I can’t guarantee that this is the only article I’ll write in this series on it. There may be more to come – so be forewarned. It’s just that it’s such a critical part of any project whether you’re utilizing it to it’s fullest extent with all tasks, resources, hours, dollars, etc. loaded or whether you’re just entering tasks and dependencies and updating it weekly with revised % complete information. It’s all tracking, it’s all project communication, and it’s all good.
Along with the status call and the status report, the project schedule is a form of communication that needs to happen on a regular basis every week. Just like team meetings and customer meetings that become irregular, if you stop producing updates to the project schedule and delivering them to you team and your customer, they’ll never feel confident that they know the current status of the project. They won’t know if what you’re delivering to them is accurate and current, from last week, or just a best guess.
This goes back to earlier things I’ve written on project management characteristics and being organized and doing what you say you’re going to do. In the project kickoff meeting or during planning sessions on the project, you hopefully set team and customer expectations on the communication aspects of the project. Hopefully, you even produced some semblance of a Communication Plan that documents when you’ve agreed to produce regular communication documents and hold specific meetings. The key is to adhere to those as much as possible throughout the project.
Is a Statement of Work Really Important?
Posted by Brad Egeland
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.
Should Requirement Quality be Measured?
Posted by Brad EgelandMeasuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.
Opportunities for improvement
If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.
Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects. Read more »
Doing the Right Things for Your Customer
Posted by Brad EgelandCustomers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?
You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.
In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:
Good Requirements vs. Rework – Part 3
Posted by Brad EgelandThe post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner. Please visit their site for more information.
As we concluded Part 2, we discussed what we all really already know – that bad requirements usually lead to cost or budget overruns, project timeframe slippages, frustrated and overworked employees, dissatisfied customers, lost profitability, and quite possibly shortened tenure with your company.
The ultimate cost of requirement errors and omissions can be huge beyond just the rework factor. Requirements drive more than just project and product quality. They drive product end-user usability. They drive the personnel skill levels for both product development and operation. They determine how the product will be used. Requirements for ease of operation, for example, lead to products that require less training before use and less time to accomplish tasks. Omitting operability requirements will result in a product that is inexpensive to purchase but costly to use. Worse, end-user operators may make more mistakes in the product’s use. Read more »