Lifecycle & Methodology | By Brad Egeland | Read time minutes
So much is said about project management best practices and performing project management by the book. Agile vs. waterfall, Project Management Institute (PMI) standards and their official PMBOK publication (Project Management Body of Knowledge) which pretty much lays out how PMI says project engagements should be run.
Following processes is a very good thing. If we managed all of our projects like we were shooting from the hip, then each one of our successes we experienced would be based far more on luck than any best practices. We would never be able to replicate what we did because there was no real plan behind it. Yes, a methodology is a good thing, a necessary thing if you want to have any hope of replicating your project successes and increasing your future chances of project success.
That said, what about the client? Project clients generally like structure, like to see repeatable processes wrapped around their projects. It instils confidence, it gives them hope that the delivery team actually CAN succeed on their project, and makes them feel as though the whole organisation is behind the project management practice supporting them with buy-in, repeatable processes and good management.
But not all clients want what your organisation plans to give them in terms of a structured PM approach. Some see PM as unnecessary overhead on the project, they may see the hands-on technical resources as the only real 'value' on the project and seek to ensure that all or nearly all of their money goes for that. Some may not want the detailed reports, the weekly status calls or meetings and all the emails, they may just want you to 'manage' it and leave them alone. And still others may want you to throw away your 'methodology' and templates and use their processes and funnel everything through their project manager.
What do you do when your PM structure is not in line with what the customer wants or thinks they need? I've run into this - we all probably have to some degree and not even realised it. When it's very evident and requires more than just a little process tweaking, this is how I usually try to handle it:
Set Expectations at Kickoff
Lay everything out at project kickoff. Go through your methodology, how communication will happen, how and when status meetings will happen, what the status reports will look like and who will get them, show them the draft project schedule, and go over all the proposed milestones and deliverables. This is the point in the project where you should discuss changes to what you and your organisation might consider their standard project delivery process or methodology. The customer may request now that it be done differently, but likely not. Often that comes up later as the project gets underway and it becomes a request or directive made by the project sponsor to the project manager on the first or second project status call. Yes, I've been through it.
Take Major Process Revision Requests Back to Senior Management
If changes to your organisation or PMOs standard project management process were requested during formal kickoff, then it's likely that someone from the delivery organisation's senior management - a VP, the PMO Director, possibly others depending on the importance of the project - were either present or participating and it may have been addressed at that time. If not - if it happens later as is usually the case - then major process changes really need to be pushed up the chain of command.
It's doubtful that the PMO Director will be happy about project managers in the organisation making significant changes to how they manage projects without some discussion and leadership approval. So, take it to your superior. If the customer wants the project manager to spend minimal time on the project because they just don't see the value, let the PMO Director help you work that out. If they want to structure how the project is run, reported on, and communicated very differently than your standard project life cycle process, then that's something you'll need to discuss with leadership and get their ok, and it may take further meetings with the project client to finalise just how the project is going to be managed.
Come Back to the Project Client With a Response
Finally, take it back to the project client or project sponsor. If your organisation is ok with running the project exactly how the client wants it run, then that may just be a quick call between the PM and the sponsor to say everything they want is fine and it's time to move forward. If there needs to be some negotiation, then you may need one or more meetings that involve the PM, the PMO Director and the project sponsor to finalise what is best for the customer and the project as a whole.
Ideally, our nice project management methodology in a box process is great and works perfectly for everyone. But clients come in all types and sizes and they are not one size fits all. They have needs, quirks, special requests. And if we want to retain their business, we often have to bend to those requests – or do a very good job of 'kindly' showing them why that's not in the best interest of the project or their needs to do so. It can be a delicate subject, so never take it lightly.