3 ms·
Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70
by icedchai 3y ago
Keep in mind all of that important but non-flashy work can also be used as a cover for not doing anything of consequence. Yes, sometimes it is important, but 70% of the time when I see someone has been "planning" they've done absolutely jack... (Recent example: How can a PM plan a software engineering project without talking to the people actually doing the work? Then they wonder why the "plan" makes no sense...)
- tengwar2 3y agoAs a PM, I find it best to put together a straw man project plan before I talk with people, then revise it progressively as I talk with people. Not always, but it's often a good idea, particularly if the project crosses multiple departments or companies. Sometimes I can't get everyone in the room at the same time. Sometimes (often) people will see their own team's area of work as being the main focus, while I have to coordinate with other groups, while trying to minimise the "hurry up and slow down". Sometimes there is a need to get people started on the bits we know about and accept that other bits will need changing. And sometimes you need to get the person responsible to estimate the length of the piece of string, and putting up a wrong estimate is a good way to get an answer. I'm sure everyone is thinking "agile" now. Yes, I was in to that back when XP was the thing. But it only works for some sorts of project, typically where there is only a single company developing a project, and the customer is internal. If you have a big contract with specific deliverables, a contractual time line, multiple organisations, and perhaps large non-sw parts, you often find that you have to start planning even before the developers are engaged, then accept that some of your assumptions will be wrong.