I’ve been in “the biz” for a few decades, so I know how this all works - or doesn’t work in many cases. I have a situation right now that is in the “doesn’t work” category that’s making me cranky. Instead of snarking on the guy who’s driving me batty, I would like to get some opinions on possible solutions I can propose to him.
So the process at this company is split in an odd way. The IT division follows an SDLC and project management and that’s all good. But the team I work for, the “business” team which is business analysts and product strategy and such, have our own thing we call the product development life cycle. The PDLC is sort of a bastardized project management system. We don’t have project managers, but we do have a small team who designs the process flow and keeps track of all the work. But they keep track of the work somewhat at a distance, not actually getting involved or controlling the projects like normal project managers would. The problem I have is that the one guy who is charged with updating the project schedules always seems to come around two days after a kickoff meeting and asks if I’ve delivered my requirements documents to IT yet.
It seems to me that he (and his manager) have no experience with software development. How else could they think that two days after a project kickoff we might have our documented requirements turned over to the development team? Even in an Agile project that’s not bloodly likely. Whenever I answer “Well, no, we just had the kickoff”, he replies with a jovial “When do you think you’ll have them turned over?” It’s all I can do not to snap back “when they’re done” because that would be unprofessional. But it feels a lot like when your boss asks you to do something that might take a week and then ten minutes later asks you if you’re done yet.
Clearly something in this PDLC process is broken. They need to track dates of deliverables but there’s nothing in the process for estimating those deliverables. Maybe when they attend the kickoff meetings, they should be asking for estimated dates at that time? What do you all think?
I feel like I’ve encountered this as well as a project manager. In many dysfunctional organizations, project “plans” as such are often defined by the business (or even worse, sales) and are based solely on the business needs of partners or customers. As they are often created without guidance from the technical team, the plan is often mostly wishful thinking.
A good project manager who is experienced with the SDLC and has possibly even been a developer will recognize these risks and try to mitigate. But more and more I am seeing people who are pure business project managers whose only qualification is they passed a 200 multiple choice question PMP exam. Typically they approach project management is simply asking people where they are with their tasks and then providing an update to management.
What this role effectively does is remove the PM from being the actual project leader. That is to say, the person who actually allocates tasks to and motivates the team, deals with interpersonal or logistical issues, provides technical advice or otherwise demonstrates that they are the most competent, most knowledgeable person in the room. Instead they just become some bureaucrat checking off % completes on a Gant chart.
Project Managers are the gnats of the IT world. Insecticide is an effective solution but probably not allowed by your company. I suppose it will be futile but try to explain that you are in a phase where no definite schedule can be determined and set up periodic progress meetings with the little insect to go over your progress toward the goal. At the meeting tell him any non-factual questions will be answered at the next meeting if they are still applicable.
Ha! I once had a project manager explain to a customer that he was not responsible for delivering the project for them. Apparently he operated part of the 'project management process and he could take no responsibility for anything beyond what he perceived as its inputs and outputs.
Luckily I had been working with the customer for a long time, we all just looked at each other and continued our meeting, everyone marking this guy down as another spare part. He made himself useful by taking the minutes of the meetings, listing the issues and action points.
Some people really do not have a clue and get totally the wrong idea about how an organisation should go about its business.
Project management is all things to all men. I worked for an Oil company where they had one project manager to develop a billon dollar Oil rig. I worked in another where a project could be as simple as getting a telephone line installed (they had a LOT of project manager, they seemed to breed like VPs in a US bank… It is a very elastic concept that is very open to interpretation.
So the PM doesn’t know how long something might take - give them an estimate! “Have you delivered the requirements yet?” “The requirements will take at least 3 weeks after the kickoff to complete, maybe longer. It’s only been two days. I’ll let you know when they are delivered”
Seems easy enough, and I work in software. Sometimes you just have to set expectations with the PM.
Yep, you guys have nailed the petty bureaucrat thing. That’s exactly what it seems like to me. The project schedules are embedded in the Sharepoint workspaces, and you can pick any project to look at and it will have standardized tasks and all the dates for every task will be the same. It’s silly.
They, and many people I’ve asked about this inside the company, insist they are not project managers. Even though the team is called “The PMO” and the lady who is in charge of the team is a certified project manager.
But to be a team player, I’m trying not to snark publicly about how stupid their approach is. Is there any kind way to tell this guy that there is a better way to update his dates? Or should I just ramble off random dates to keep my own blood pressure low and see if there are any screams down the line? It might be kind of fun to play with the process a little…
Part of the challenge is that one of our PDLC phases is called “discovery”. It means essentially doing R&D, customer interviews and other tasks to discover exactly what the project should be and to evaluate if it’s worth doing. I don’t know - and we don’t have any published method - to estimate how long that should take. And it comes to a head on two projects I’m currently assigned to where someone above me decided to combine the Discovery and “Justification” (i.e. writing requirments) phases.
Is the project the revision of something standard, or something totally new? Because etas are very different in these cases.
When I was running a small team doing researchy kind of stuff, my algorithm was to poll the developers for their estimates, double the longest, and add two weeks. Of course you have to get a feel about how optimistic the developers are - you might need to triple the longest estimate.
Requirements changes require a reset of course. That might help train requirements writers to get it more or less right the first time.
The more risky the project is, the less accurate the schedule will be. Scheduling tools are not very good at dealing with rework. That’s why the examples in their manuals are about stuff like putting on plays and building houses, things with known requirements and times, unlike software. And as the old Spiderman musical demonstrates, even plays can slip.
Ideation phase: somebody gets a great idea (customer or internal). There’s a little discussion about it, it gets a value-to-the-customer added to it, and it gets prioritized in the list of stuff to do.
Discovery phase: as mentioned, this is primarily research and super high level design. Customers are interviewed in more depth and possible solutions are documented. The teams (developers and business analysts) are asked for super-high level estimates for the solutions (basically wild ass guesses at this point).
Justification phase: one solution is identified for development and high level requirements are drafted and the teams (developers and business analysts) are asked for more refined level of effort estimates for the solution.
Actually, while typing this it occurs to me that they (the PMO) should be using those estimates to derive the dates. Duh!
It sounds like you need a process. Or at least an outline of the steps. And an understanding that the discovery portion of any project is going to take a while - if you can’t get the people who need to itemize out their requirements together because their calendars are booked, then it doesn’t happen.
Itemize out what you do.
Schedule a requirements meeting with the customers - one or two weeks of elapsed time to get on everyone’s calendar.
One week to assemble their input into high level requirements.
At the end of that week, meet again to review and confirm.
Two (or three) iterations.
Deliver finalized requirements.
Then call this guy and his manager into a meeting to say “this is how I think the process should run, and if we run it this way, we can expect X weeks between kickoff and requirements delivery, assuming I don’t work around holidays and vacations and can get onto people’s schedules. I believe if we do it this way, we will turn better requirements over to IT and save time on the development side. If it needs to go faster, we need to figure out what the deliverable is - is it customer meetings, or is it a very high level product description - and this work needs to get moved into the SDLC.”
What’s the reporting structure within your group? Are you and the idiot peers? Same or different manager?
If I were in your shoes I would first talk with my manager and get their input. Perhaps you could suggest that some clarification to the entire group would be helpful re: milestones, what’s the significance of the kickoff meeting, who starts working on what after the kickoff (your group vs IT), etc. Or you could suggest this to whoever is head of the process flow team.
If the guy is that much of an idiot, starting by going to him directly might not be the best idea. I also wonder how he got the job. If he friendly with someone higher-up?
Why is the project manager or whatever he is called asking you for deliverables when an overall delivery schedule doesn’t seem to exist? The PM should be working with you and the other developers to put estimates around when those deliverables can be completed and how they integrate into the overall project plan.
Developers always like to bitch about project managers, but having a good project manager is the difference between you working until 2am every night on what will likely be your last project at the company and going home at a reasonable hour.
Developers are also notorious for overestimating their coding ability and their ability to “catch up” by working a few extra hours. There’s also a tendency to short-change QA time, thinking that it’s just an optional schedule buffer.
Sadly, “project manager” is often the worst job in the company. You typically have to “manage” project sponsors and stakeholders who expect you do deliver to unrealistic schedules while dealing with developers and other resources who you often don’t directly manage or control (who typically don’t like being put on a schedule). It’s probably why there’s so much spam from Indian recruiters looking to hire PMPs for 3-9 month contracts.
The thing that should occur in any project is to have a meeting to “plan the plan”. This should be a huge overview with a timeline schedule, milestones, deliverables and what is the entrance and exist criteria at each phase. Without doing this upfront and carefully, the project is going to run into a series problem along the way and it isn’t from lack of effort, it’s because people were given proper direction from the start. Doing this helps define what needs to be determined how as much as possible instead of waiting for the middle of the project, and start making an inquiry about resources or expected date of a deliverable.
Giving an answer or even thinking “When it’s done” is unprofessional. If you have say a 12 month project, and you know you are going to need documentation at some point for others to do their work and are being asked about it now, if you don’t know the answer you should get back to them with an answer. Now, before anyone gets into the “It’s too complex and can’t tell you how long it’s going to be until it’s done” that’s just a lack of good project management skills. Because there is always a history of previous work and often it’s going to be similar work. There is an art and science to doing estimates, which is the best anyone can do. Not pulling a number out of your ass, but actually talking to people who have done the work before and coming up with the amount of effort and resources were needed. This gives you a good estimate.
It’s OK for the business segment to do the plan, after all, it’s way the project is being done. But then they need to bring in the people doing the real work and find out what is and isn’t possible. Often times what is impossible can be negotiated to make it possible.
It is this attitude, why in business meetings they look at the cost of the IT department and decide to out-source the entire project and lay the IT staff off. Because with an out-sourced company they want to do the work and will work with project management and the business to achieve the goal. Get no respect from anyone claiming there is no definite schedule, pick up a pad of paper and start asking questions and set one. It isn’t rocket science.
Exactly. Even people who create paintings for a living give an estimate to the client when the work will be completed and that’s pure art. This is engineering, no reason not to be able to come up with estimates.
In other words pull some numbers out of your ass. No definite schedule doesn’t mean as long as it takes, it means you need a certain amount of information before you can make reasonable estimates. If you don’t have that information any schedule is pure crap. Come up with a deadline if you want and then the process becomes determining what can be done within that time constraint. That at least will give you a chance at meeting an artificial deadline. And if in-house development team can’t do the job you need then out-sourcing is exactly what is needed. Just don’t blame the developers for what is always a failure of management. If you can’t tell whether or not the estimate given to you is realistic then you shouldn’t be doing the job.
I think a lot of you missed my latest post. We do provide estimates to the PMO. They still come pester us for dates. After some pondering, I think maybe what they’re trying to find out is if we’re going to meet the dates or running behind and are doing it very clumsily. Instead of asking two days after the project kickoff if we’re done yet, they should ask if things are on schedule. That would get less friction, I think. Although the way they operate - not really managing the project, just recording dates while not participating in the project meetings - is still dumb. To give them some leeway, though, they are only three people (the manager, the date guy and one other person) and I doubt there’s any way they can manage around 15 projects simultaneously, which is our usual load. Personally right now I’m on three projects, plus two large non-project tasks.
We do have a problem with getting approval for staffing. But kind of… you know… who doesn’t these days?