How do you fight the battle within an immature organization that does not understand the value that a structured project management process adds to an organization? Our IT shop is used to just winging their projects and is resistant to change and see its PM as a roadblock to getting their work done. Saving Changes...
Sort By:
Anonymous
Need to bring in process iteratively. Start with making them plan out major tasks on the critical path and make sure you have an owner and due date. Then review the plan weekly. If a due date passes require a new day. Someone telling you 'soon' does not cut it. If you keep consistent then it soon becomes the norm.
Before they will follow anything though they must first trust you. If you don't have their trust (and you don't hold the power) then you wont get anywhere. Saving Changes...
Patrick NortonEngagement Manager| Twin TechnologiesTimonium, Md, United States
I've found A key ingredient to successful adoption is "buy-in" from all involved, particularly in a growing organization. In order to achieve this, I find it useful to stray away from typical PM buzzwords thrown around without explanation. Handing out software design templates is not the way to go and will result in fairly stiff resistance. I like explaining concepts and WHY their implementation is a value-add. For instance, the existence of change control helps developers by not pushing onto them extraneous customer requests while retaining the same deadlines. You will be a hero when you execute this key PM paradigm. Afterwards you can explain that change control can only be achieved by articulating and documenting the project goals in the beginning. And so on and so forth. Saving Changes...
Peter WrightProgramme Manager| BAE SystemsSouthport, Merseyside, United Kingdom
Hi Anon
There have been various threads on this previously and I have experienced this issue first hand. If the direction from Above / senior management are not bought into the improvements a new process can bring then you are likely to flog a dead horse pushing the actual doers into the new process.
People will always be resistive to change / fear change and you have to sell to them the idea that it will improve their working day / save them time / reduce the management noise etc.
When implementing a PM structure spend time getting from stakeholders what the core business operational issues are and then, IF possible quantify them which will give the the base for the business case figures to show the benefit the change will bring at the top level.
Change always has to be sold correctly and not over sold also as people will always be cautious about the figures the benefit will bring.
If the business is used to winging it try implementing a less formal PM structure and documentation, keep PID's, approvals to a few pages / kept on Wiki's do not think you have to implement a full blown fully documented flow from the start and you may well win a fwe of them over.
As an example in a previous (sounds like a similar business to yours) documentation and information was kept on Wiki's, designs and data were also kept on the wiki's and as it was IT / Development teams they were very comfortable with this opposed to documents.
Saving Changes...
Taralyn Frasqueri-MolinaSenior Project Manager| Independent ContractorPasadena, Ca, United States
Here's my question... is the organization failing in meeting their project objectives? If they're are doing just fine, even by winging, then maybe we as PMs need to quit picking.
But, if they're not doing so well in projects, or could do a lot better, then I suggest structuring your conversation with what the immediate benefits of following a standardized process would be.
What worked for me was telling people - well... right now we're failing without a structured process... soooooooooo... why not try something, and if it works, great! If it doesn't, no loss. I also let my team know that I would be doing most of the work during this transition and that I would let them know exactly what I needed from them. People are more inclined to try something new if it means there won't be extra work for them.
If you have project managers in your personal business network who are leading successful project, invite them over to your job. You can introduce your team to your contact and let the contact talk about how well project management is going for them.
I might also point out that your internal thoughts and mood about an organization and the people in it will usually come across in how you approach and talk to them. You use terms like "fight a battle" and "immature" and "does not understand" - which are fairly harsh. An organization that is new to project management, is like a newborn. They look fully functional, but need a lot of help growing up. That takes a lot of hand holding, explaining, re-explaining and patience.
I wouldn't fight a battle with an immature organization. I would invite my intelligent co-workers to lunch or to tea to talk about how I could help them be even better at what they do.
I agree with Taralyn, you can only introduce structured PM if there is a problem to fix. One problem though is that without the PM artifacts such as charter, schedule, scope, benefits costs etc how do you know you have a problem? You can't fail to deliver to time, cost and scope if none of these are documented ergo no problem!
Try doing some Post Implementation Reviews on a couple of key projects and see what drops out of that. Once you have a "problem" you can start providing the solutions. Saving Changes...
David R. CampbellProject Manager| Ghandeel.orgMaquoketa, Ia, United States
I feel for the original (Anonymous) author, as I am also in an immature organization. Fortunately, my boss (VP) brought me in to lend structure, so I have leadership buy-in from the start. Initial problem was that the VP was not being kept informed as to status, and they had just started using an online PM software (Basecamp).
I've managed to convey that a simple (one page) Project Plan is needed to let someone looking for information know how the project works, and made it mandatory that PMs file Status Reports weekly.
As the PMs are getting into the routine, the VP is more comfortable, and leadership distress has lessened considerably. Like any new habit, they were awkward at first, but now it's becoming easier.
Next Step: Charters, estimations, and a master schedule Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
There's lots of good advice in this thread. I'll just add my thoughts: make it clear what you mean by PM structure, as for many people this translates as "lots of documents". If you can present structure as actually very light on documentation, then this make make it easier to show people the benefits. We manage some small projects with a one page scope document and that's about it, so PM structure does not have to be cumbersome at all. Saving Changes...
Bruce LoflandSoftware Developer| SprintLenexa, Ks, United States
I agree with Elizabeth that you don't want to introduce a lot of documents that other people have to produce right away. There is a lot of good advice already given here to which I will add mine.
Define when a project is done. This can be done in the project charter. At first this may be very informal like an email between you and the project sponsor that you share with the team. It may say in a bulleted or narrative form what the project is and how you know you are done. This does not take a lot of time to produce or read, but it provides a lot of value in keeping the team focused and controlling changes to scope. From there, the other disciplines will emerge.
People won't change if they don't agree that there is a problem or unmet need.
Start by documenting the existence of a problem - start recording promises made and missed. Use these as learning opportunities to demonstrate the impacts that these misses are having on the business operations, revenue generation or customer experience, etc.
Once there is agreement that there is a problem start asking the team what can be done to improve the situation. 9 times out of 10 they will start introducing some elements of discipline. Facilitate the discussion to lead to an agreement about some new practices that "might" help.
Identify a pilot efort to "try" some of these new processes on. Use a light touch. Don't throw too much bureaucracy at these anarchists too soon. You want to demonstrate that the process can be used to help them (e.g., prove we need more resources, prove we need to adjust delivery dates, prove we need to implement in phases, prove we need to manage scope creep, etc.) The goal of disciplined oprocess is to identify problems early and resolve for least cost/impact. This should help your teams, once they believe that purpose is not to pound them personally for missing dates.
Most importantly, you will have a body of information that can be used to defend and support the teams in larger discussion venues, so they can move off of the defensiveness posture of "why don't you trust me."
If you can make the case that this to improve the chances of success without adding extra burdens to the poor mules then you will win the battle. Start small and take baby steps, and document the results. Saving Changes...
