The Evolution of a Project
Posted by Brad Egeland
Projects typically begin when we recognize that a need exists. From this point on, however, we can often become our own worst enemies—and can lose control very rapidly—if we don’t follow a disciplined approach. Why? Because we’re human. When any of us spots a problem, our natural tendency is to want to solve it right away—often with the first solution that pops into our heads. That’s just human nature. On the surface, this approach may seem admirable, because it seems to resolve problems swiftly and decisively. Unfortunately, it’s counterproductive to good project management. A solid approach for getting your project off the ground consists of faithfully following four basic steps.
Fully understand the problem or opportunity
Problems are ordinarily complex, consisting of many aspects that require analysis and insight. There’s frequently more to a problem than what’s apparent at the first look. We need to invest an appropriate amount of time to fully understand all aspects of the problem. Very often, what appears to be the problem is actually masking a bigger, more fundamental problem. Uncovering that fundamental problem is referred to as identifying the true need.
Identifying the client’s true need—the most fundamental problem or opportunity—is the first and the most important step in the entire project process.
A Project Completion Checklist
Posted by Brad EgelandAs the project comes to closure, it’s time to look back and enjoy all the successes you’ve
experienced on the project. All the memorable learning moments and all of those leadership situations that have allowed you to grow as a project manager. Not! As the project comes to closure, you’ll usually find yourself knee-deep in administrative and signoff tasks not to mention work related to those tedious remaining issues that make the customer very nervous at deployment time.
Your duties as project manager and leaders extraordinaire certainly don’t cease … they actually increase. You’re dealing with lots of things going on at once and you’re also dealing with two separate sets of team members – yours and the customer’s – who are being pulled by their respective organizations to free themselves up for new and exciting projects. They’re working in shutdown mode and it’s difficult to get the productive hours out of them for YOUR project right now. It can take all of your resource management skills just to keep team members engaged.
Customer Issues
- Complete all deliverables
- Install and test deliverables
- Prepare operating manual
- Prepare maintenance manual
- Train customer’s personnel
- Agree on level of follow-up support
- Conduct formal acceptance review with customer
- Verify customer satisfaction
Project Communication Series: Planning Meeting Agenda
Posted by Brad Egeland
I wanted to use this series as examples of basically all the types of communication that can and does happen on a project. Since I have no real vision yet of format, it can really be anything. Specific examples, templates, etc….anything worthy of discussion as relevant and necessary communication on projects. I still feel that effective and efficient communication is the most critical responsibility of the project manager. If our readers on here have suggestions of things to cover as part of the communication series, please send them to me or comment on this or subsequent articles.
Below I’d like to present something I found in Carl Pritchard’s book, “The Project Management Communications Toolkit.” It is basically a template for the project planning meeting agenda – which, as we all know – is a very critical team-to-team communication point on any project.
Here is Mr. Pritchard’s summary for this agenda….
Purpose
Project planning meetings are held, as the name implies, in order to develop all or part of the project plan. They are intended as both data gathering and data-organization sessions. They are intended to generate not only the project plan, but a consensus on that plan and its implementation. The agenda serves as a guide for how these sessions will be held.
Five Signs You’re Not Cut Out to be a Project Management Consultant
Posted by Brad EgelandConsulting, in general, is not for everyone. Likewise, consulting it the field of project
management 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.
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.