Four Project Decisions You May Regret Later On
Posted by Brad Egeland
Sometimes, depending on the size and visibility of the project, there is a tendency to want to cut some corners on. This may come about due to pure laziness. Or maybe it comes as a directive or request from your executive management. However it evolves, it can be a slippery slope and it can cause big problems on your project. You may have to ‘scale’ your best practices for the project depending on its size and budget, but it’s never a good idea to skip key activities altogether – even if you’re being told to do this by superiors. If the directive to cut corners is coming from above, you may need to educate them on the risks that are invited into the project by eliminating key best practices steps along the way.
At any rate, it’s important to pay attention to detail no matter how big or small the project is. And, given that thought, I’ve outlined four poor decisions you could make on your project just to save time or money – these could come back to haunt you in a big way later in the project. They are:
Skipping key up front planning documents
What you or your customer may consider time wasters are actually building blocks to good project documentation and understanding. Even if the customer isn’t paying for the early planning documents some of them still should be created – especially ones like the Communications Plan, the Risk Plan, and the Change Control Document outlining how project changes and change orders will be handled. Creation and signoff of these plans at the beginning of the project will ensure everyone understands how to handle these issues and processes when they come up and customer satisfaction will be higher as a result.
Not putting together a detailed master schedule
This should be done even for the smaller projects. A detailed project schedule created and distributed early in the project provides the customer and project team with a solid understanding of the tasks, goals, level of effort, and timeframe for the project. Even if the project is extremely simple and you never update it after the first creation, it will still help your project team and customer – and you – far more than you realize.
Not creating a requirements traceability matrix
Thorough requirements documentation with a matrix to trace the requirements through the design and development of the solution will help ensure that key requirements aren’t missed in the process. With a requirements traceability matrix, you’ll be able to document how and where each customer requirement is met in the solution.
Do We Need Customer Participation on Projects?
Posted by Brad Egeland
Now don’t laugh – this is a serious question. There are projects or programs where the customer basically hands off their needs or requirements or whatever and they basically just “phone it in” for the rest of the project. I’ve been on those. They’re not bad – as the project manager you pretty much have free reign as long as you keep producing status reports and show that you’re on target.
But is this a good thing? Sure, we’d all appreciated it from time to time if our customer’s would stay out of our hair. It would make our jobs a lot easier if we could work on the project without phone calls, questions, and demands from the customer, right?
But what are the downsides? What could possibly happen on a project where the customer remains uninvolved throughout? Let’s look at some of the more obvious negatives:
Cost to the customer
A typical professional services organization is going to charge its customer – on average – close to $200 per resource hour. If no one is participating from the customer side, it’s going to take more delivery team hours to gather the necessary information, correct requirements, manage the project, and provide a final, workable solution. It wouldn’t be a one to one trade off on customer hours versus vendor hours, but customer hours would not be costing them $200/hour. Every hour the customer spends helping to manage the project with resource that is costing them, say, $50/hour, can actually result in a decent savings over the course of the engagement.
Requirements issues
If the customer throws their requirements over the wall to the vendor at the beginning of the project and offers little participation beyond that, you can be certain that the delivered solution is going to miss the mark on a few, if not many, real requirements. Much as we’d like to believe that requirements can be set in stone at the beginning of the project, that is almost never the case. Understandings and details change, customer grow to better understand their needs, and the delivery team arrives at a more thorough understanding of the true requirements through ongoing project discussions with the customer. If those things can’t happen, then the end solution is likely to not be what the customer and its end users need.
Who’s More Important to Please – The Customer or Your Management?
Posted by Brad Egeland
I ask this question from the perspective of the W2 employee. If you consider this from the independent consultant angle, it gets too messy. In the consulting scenario, often your management in the PM role is YOUR customer and their customer is also YOUR customer. So, for the purpose of this article, I’m really just considering direct hire employees.
So who’s more important to please – your management or your customer? As a project manager, I always consider my customer to be the number one reason I’m carrying out a project. It’s their money and I’m trying to help get them to the solution that they are looking for – or at least the one that they really need (even if they need educated somewhat along the way). I’ve often been frustrated at the roadblocks that management has put up in front of me – rather than knock down – along the way to project success. And on at least two occasions the path that management has directed me to take on a project has led to utter disaster. I’m not saying my path would have yielded success, but the likelihood of success was definitely higher.
So for me personally, I err on the side of the customer. That is probably what makes me a better consultant than employee. In a perfect world you have management, a PMO Director, and an executive staff that is involved and helps build paths to project successes. But in more than half of the PMOs and project situations I’ve been involved in as a W2 employee that has not been the case. How can I tell beyond my own frustrations? Well, in all of those organizations either the PMO was eventually eliminated, the PMO Director removed, or the company shut down altogether. So in those instances, I’m banking on my opinion over theirs.
A Project is Not a Work of Art
Posted by Brad Egeland
Process is important in project management and being consistent, having repeatable processes, and usable tools are all part of the necessary components to project management.
But beware of overkill.
You’ll find, as you go through life, that not everyone values things the same way you do. And not everyone values things the same way logic tells you they should. You and I both know that project management is important. It’s what I would consider to be a critical piece to any project. Done right, and it can greatly increase your likelihood of project success just through maintaining best practices. Done wrong, and it can kill a project because people relying on that project management component will find that things weren’t managed well, budgets were overrun, deadlines are therefore missed, and customer satisfaction is low. It’s about meeting expectations and fulfilling a key role for the benefit of the project.
Now consider that not ever customer cares about project management they way we think they should. Some may even consider it an unnecessary expense. When those professional services organizations provide customers with resource prices and they see the project manager bill rate of, say, $150/hour, they may hit the roof.
Three types of customers
Some see the benefit, others have a hard time stomaching paying that much, and still others may completely despise the project manager seeing them as useless overhead managing something they could oversee themselves. To those, I say let them try because you’ll likely never please those hardliners until they’ve had the chance to fall flat on their faces all by themselves.
What Does it Cost to Get the Project Work Done?
Posted by Brad Egeland
A major component of the project plan is cost. Cost management, however, is more than just calculating the cost of the overall project. It also consists of creating a budget (identifying the cost of individual elements of work) and the time-scaling of the overall project expenditure. First, let’s look at some basic definitions.
Types of Costs
Estimating and budgeting project costs is not as easy as you may think. One reason for that is because there are so many types of costs that you should include in your estimate. Also, there’s the overriding issue of direct vs. indirect costs. There is a definte distinction so I’ll clarify these further.
A direct cost is an expenditure specifically and directly incurred by the execution of your project. These are typically the most obvious categories of costs, and include the following:
- Labor: The cost of the people carrying out the activities on your project. This could include contract labor. This is often the largest component of the project budget.
- Materials: The cost of items purchased for use in executing the project.
- Supplies and Equipment: The cost of items consumed by the project and specifically required to execute the project. This item could include items that are purchased, leased, or rented.
- Facilities: This would be included only if the facilities are built or purchased solely for the use of the project (in other words, when it’s part of what the project delivers).
- Training: Training specifically required to achieve project success. This cost is often associated with customer training during installation or startup.
- Travel and Other Miscellaneous Costs: Again, the only rule is that the cost must be required to execute the project.
