Selecting the Right Project Management Software
Posted by Brad Egeland
It’s no longer a given that today’s project manager is going to just default to Microsoft Project for all of their project management and scheduling needs. While it remains an industry mainstain, as a standalone tool it’s expensive and offers no collaboration features. Implementing MS Project Server can turn it into a valuable project collaboration tool, but that’s considerably more expensive and not straightforward at all to implement. And today’s PM world abounds with desktop and web-based alternatives that are capable of doing the job for much less.
First, however, let’s look at the big picture. Project management software alone does not make a person a good project manager nor can it ensure that the job is being done well. I believe there’s too much emphasis and too much reliance on project management software – in particular, scheduling software. Some who are relatively new to project management view scheduling software as the totality of project management. This is very dangerous. Although no one can deny the incredible computing power of scheduling software, an inordinate focus on it belies the breadth of the project management discipline. Project planning is so much more than just a schedule. And project management is so much more than manipulating a software tool.
Also, excessive reliance on the tool tends to discount the importance of the “art” part of the project management. Efficient and effective communication along with the ability to manage project resources effectively is the key to project success.
Choosing the right tool
People often the question: “What’s the best project management software?” The standard answer in project management is …it depends. The topic of software selection is no different. It depends upon a number of factors. Here are some of the factors you should consider, examine, and compare before selecting the “right” software for you.
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:
