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.
May 2010 Survey Results: Equipping the Project Manager
Posted by Brad Egeland
The results are in for the May PM survey on equipping the project manager. The response rate was very good – many thanks to our readers who responded because without you there would be no survey and no fun follow-up analysis.
In terms of surprises, in my opinion there were four key surprises that I will describe in my run down of the results below…
Formal PM Methodology
Here’s the first surprise: only 53% of the survey responders indicated that their organization followed a specific project life cycle or project management methodology. That means that 47% are basically ‘winging it.’ While that’s ok on occasion, it’s very difficult to realize long term organizational and project success without some sort of consistent, repeatable process in place. Nearly half of our survey responders don’t have that and that’s concerning.
PM Software
No big surprise here … 58% use Microsoft Project as their primary tool for managing projects. What was surprising is that a full 26% are not given any specific tool to use when managing projects. Back to the ‘winging it’ concept… not good. 11% indicated that they utilized a web-based PM tool and 5% indicated that they use some desktop tool other than MS Project to schedule and manage projects.
Accidental project managers
Posted by Elizabeth
At a recent British Computer Society Project Management Specialist Group meeting in London, Miles Shepherd said that people of his generation “became project managers by accident,” often as a result of having an engineering background.
Accidental project management is the way that many project managers are created, even now. Bas de Baar has written a book called Surprise! Now You’re a Software Project Manager
I also became a project manager by accident – kind of. When I was at school I didn’t know project management as a discipline even existed. I wrote lists, I did my university work in a structured and organised manner, but no one ever told me that I was managing projects and that I could make a career out of it. And I never asked. Once I was working, I saw people doing project management jobs and realised that was what I wanted to do myself. Knowing that project management roles existed was the first part of getting into it, but once I realised that I specifically sought out roles to apply for in the business change and project management sphere.
The Importance of Setting Customer Expectations
Posted by Brad Egeland
Miscommunications happen all the time. They probably happen at your home everyday. How many times has your wife or husband said they told you something or asked you to do something and you have no clue what they’re talking about? I’m hoping that’s not just me.
The same can hold true with our customers. While we try to document communications with our customers and get their signoff on expectations and understanding, that doesn’t always happen – or what we sign off on may be a generality when in fact the details are up for interpretation. And, yes, some of that is just unavoidable because you can’t capture all details of a discussion unless you’re going to record every communication – and that’s just not reasonable either.
Customer disconnects
Disconnects in customer communications and understanding can happen at a number of points throughout the engagement. They can happen:
- During the sales process
- During project kickoff
- On change requests
- On status calls and in status meetings
- During every informal communication that takes place, though less likely in written form like emails
That last statement says a lot – when we put things in writing the likelihood of a misunderstanding or a incorrectly set expectation often diminishes. But I will never say that all customer communication should be handled via emails. That’s not practical and it takes too much of the human element out of the communication. However, email is an essential tool for delivery team–customer team communication and is often a great way to follow up to confirm understanding.
Actions we can take
There are three ways, in my opinion, that we can work to ensure that customer expectations are in line with what we – as the delivery team – see those expectations to be. Remember, there’s not guarantee and there are just about as many possibilities for interpretation as there are fingerprints on record … I’m trying to say we’re all different. But these three actions can help to ensure that we’re all on the same page during the engagement.
#1 – Revisit the sales information with the client prior to kickoff
Prior to getting together for a formal project kickoff, meet with sales to understand how that process went and to get any of your questions answered that you might have concerning the sales handoff materials you’ve received. Then, meet with the customer – still prior to kickoff – to discuss the engagement at a high level and get more questions answered so that you can head into the project kickoff phase with your best possible understanding of the project goals and information.
