Are You Using the Tools, or Are the Tools Using You?
Posted by Brad Egeland
We have all kinds of tools to get information concerning our project distributed to the right people, don’t we? We have MS Project or similar projects like Seavus’ Project Planner to use for managing our project schedule. Word helps up put together project status meeting notes, project document and plan deliverables, and status reports. Sometimes Excel can do the same – plus it’s great for project budgeting and forecasting. For resource management it’s back to MS Project or another project scheduling tool or you can do it the old fashioned way with a spreadsheet like Excel. And Visio helps us put together meaningful flowcharts for functional and technical design documents and other related project materials. Finally, email is often our primary communication tool on projects. Since communication is probably the most critical function of the project manager, email is in heavy use throughout every engagement.
Throughout the project, the project manager and the rest of the project team are utilizing these tools to create visual, professional, and hopefully meaningful and useful project documents to give to the customer and show to the organization’s executive management. In fact, if the project manager is overseeing five or six or even more projects at once, the creation of these documents and files with these tools can end up taking most of his available time. Especially if accuracy and perfection is a goal – and it should be.
Don’t forget the personal side
What we need to always be aware of, however, is that our customer needs more than just information about the project. And for communication they need more than daily emails. It isn’t always about what we can produce for them and how professional it looks. The project manager must be able to connect with the customer on a more personal level than with schedules, charts, and reports. In order to maintain the highest level of customer satisfaction, the customer must feel like they are ‘in touch’ with the project and the project team. That isn’t likely to happen if all they see are emails coming their way with information and professional-looking document attachments.
If the BP Oil Spill Were a Project…
Posted by Brad Egeland
If the BP Oil Spill were a Project, would the cleanup and well capping process be going differently? I’ve been asking myself this question a lot this week so I figured it was time to put words to down and see what our readers come back with.
I have to believe that British Petroleum (BP) actually is treating this issue like a project, but I’ve never seen so much back to back failure in any project I’ve ever managed or witness from a distance so it’s truly hard to believe that PM best practices are being applied to this one.
Here are the facts we have so far:
- Oil has been flowing freely for 46 days so far
- A low end estimate of per day oil flow is 210,000 gallons
- That’s 9,660,000 gallons spilled over the 46 days
- The White House has just sent BP a $69 million bill for cleanup efforts
These numbers are amazing and shameful all at the same time. And there’s almost no end in sight due to BP’s repeated failures to make progress on capping the well.
Questions we have to ask?
- Did BP do on-going risk analysis?
- Have laws been broken?
- Should any BP executives still have their jobs when this is finally over?
- Do you think the BP Project Manager will ever get another gig?
This may not be the case, but each new attempt to cap the well or channel the oil flow to a surface ship seems to be a new shot in the dark and continually ends in failure. It’s easy to say that customer confidence is at an all time low right now for BP. Each new attempt needs to be treated as a separate project – or at least a separate sub-project with planning already in the works for the next attempt. Potential issues need to be reviewed, risk analysis and risk mitigation discussions need to be happening 24/7.
More on Pleasing the Customer and Management
Posted by Brad Egeland
Already my recent article on “Who’s More Important to Please – The Customer or Your Management?” has generated interesting discussion and feedback on LinkedIn. Hopefully we’ll start seeing some comments here on PM Tips as well.
In response to the discussions that are going on so far, I’d like to follow up with some thoughts on the matter.
The general agreement among responders is that both need to be important – and I agree. Also, it is being said that a talented project manager will make it apparent to both the customer and their management what is important and align the goals of each. I agree on this as well – in most cases.
The issue is, most of us have been in one or more poorly planned or poorly run project management offices or organizations with poorly run project oversight. In some of these cases, it really won’t matter how talented the project manager is, if management doesn’t get it, isn’t focused on project successes, or is often trying to ‘solve’ things behind the scenes before taking it to the customer (and by that time making it too late to resolve the real issues) then there’s not much that can be done.
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.
Why the Business Analyst is Your Best Friend
Posted by Brad Egeland
A quick check on Wikipedia shows this high-level definition for a business analyst…
“A Business Analyst (BA) analyzes the organization and design of businesses, government departments, and non-profit organizations; they also assess business models and their integration with technology.”
In my years as a project manager – and there have been quite a few – my experience with the business analyst has always been this… they are basically your very technical bridge to the development team. They capture the business requirements and work with the development team or technical lead to translate the business needs of the customer into technical requirements that the developers can build the solution from.
Obviously, if this is not done well, you’ll have the same age old problem. Your development staff on the project will be building a solution that doesn’t match up well with the actual needs and requests of the customer. The customer end user will be unhappy, customer satisfaction will be low, your job will be in jeopardy, and so forth. You get the picture … and it’s not pretty.
The business analyst – in my view and in my experience – is the glue that ties the non-technical and the technical together. As a former techie and an IT project manager, I can fill both roles if necessary on a smaller project and have on several occasions. But I’ve seen none technical project managers without any technical training try to do that and fail miserably. On my larger IT projects, I don’t know what I would have done without a very experienced business analyst who understood the business needs and was able to translate those needs well into meaningful requirements for the developers. It would have been a disaster.
