Ask Slashdot: How To Gently Keep Management From Wrecking a Project? 276
New submitter miserly_content writes "I work in a large, hierarchical technology company. I have been developing technical specs for a new strategic and challenging software project, and the project is slowly gathering steam and support. This is already a career building success for me, and everyone acknowledges my technical capabilities. But the program manager is an MBA-type, and wants to bring in new multiple team leaders and consultants. This is not really a surprise, but I feel we are sliding towards a too-many-chiefs-too-few-indians scenario, especially at this early stage. How can I pitch upper management about this issue, without appearing selfish or disruptive? What positive approach can I try with the PM, with whom I have a good working relationship?"
solve your problem small (Score:5, Insightful)
In these situations, I think you have to solve this problem as small as possible, with the program manager themselves. Figure out what that person feels isn't being delivered or executed on, and make sure you address that manager's needs.
Escalating around the chain of command doesn't usually work in these scenarios, especially if you're relatively new.
CYA (Score:2, Insightful)
Your manager is covering his ass. Inserting layers of management between you and him so when/if things to go wrong, he can scapegoat consultants and team leaders.
Do Nothing (Score:2, Insightful)
ot at the very least very little. Have a water cooler chat to the MBA type. Explain what you want.
I know it is your baby and you don't want to lose it, but business is business. It will either work or it won't. No point making too much noise.
Maybe you are wrong (Score:5, Insightful)
As A Boss... (Score:5, Insightful)
I feel a large part of my job is to stay out of the way of my developers.
However, we are part of a much larger, ISO-9001 process machine, so it is very difficult to remove the process overhead.
I try to take on as much as I can, so the engineers don't have to weather it, but the process demands that they all have their part checking boxes and attending meetings.
The good thing about a process-driven organization, is that everyone knows exactly who will be sticking their nose in, where, and when. You can't just stuff extra clowns into the car whenever you feel like it.
Re:Stay focused on goal (Score:3, Insightful)
Re:solve your problem small (Score:5, Insightful)
Yep, this can be applied to almost all cases where you don't understand why someone is doing something, or why someone is arguing for something that you don't want.
Rather than going to them and saying "don't do that, it's idiotic", go to them and find out *why* they want those things. Then explain the reasons you don't want them, and come to the solution that satisfies both sets of needs.
It amazes me how few people are able to do this, and instead bang on and on about how their solution is the one true solution without ever understanding all the competing needs.
Don't go above your manager (Score:5, Insightful)
Whatever you do, do NOT go above your manager. It never ends well. And don't ask me how many times I've learned this lesson, but at the time I didn't care. Bosses are usually more clever, savvy, political, and better at justifying their tenuous position. They will always crucify you, no matter how good you are. Unless the boss is doing something literally criminal or otherwise worthy of employment termination, just don't do it.
Start with the PM (Score:3, Insightful)
About "M.B.A." (Score:5, Insightful)
MBA programs are full of pseudoscience and hard-science envy. Most of that social science crap is about dumbing-down things so that they nicely fit into a simpleton math theory. Worker qualification and experience cannot be "measured", so it is ignored. Workers are slaves who must be replaceable any time just like capital goods. MBA theory hates every expert who cannot be replaced quickly and cheaply, because it threatens the power position of the social science people.
See the sorry state of the nation that invented "MBA". Compare that to a nation led by engineers which propelled itself from crapbin to #2 in 30 years time. See the sorry state of M$ and compare that to Google or Apple. A unique person like Steve Jobs does not fit in their dumb-down pseudo-science theories. "A good manager can manage anything" is their motto, because that is the basis of POWER. And that is what they want - power at all cost for THEM.
Let's wait and see how the dominance of the social science crappers works out for the western world. So far, the future looks very dark with pitchforks, Guillotines and more on the horizon.
Re:Three rules (Score:5, Insightful)
Put all of the project management records in a tool or data set they're not using. Give them only aggregate data.
Stop inviting them to meetings.
Don't use corporate e-mail.
Three good ways to get fired.
Re:Maybe you are wrong (Score:5, Insightful)
Sorry, but I'm thinking that the subject line of your post is beyond the comprehension of the average Slashdot poster.
Work with your PM & you will both go a long wa (Score:5, Insightful)
I am a Program Manager that's worked for a number of leading global companies delivering multi-million $ global IT projects over the last 15 years.
Part of my role is building relationships and facilitating collaboration to achieve success - not just of the projects but also of the individuals on my projects. Both are very important to me and usually the companies I work for and with e.g. suppliers, SIs, customers, etc.
Have a good conversation with your PM, I'd suggest go for lunch/coffee so you've longer to talk. I've used 'him' below so apologies if its a 'her' ;-)
Tell him;
How much the project means to you and what you've put in personally so far.
What the possible successes are - not just of this project but what it could lead to for your company, your customers, etc.
Show him your plan for what the tasks are, when they will be done and who will do them. If you can build a basic time line/table in a spreadsheet showing what will happen by day/week/month. If your using Agile then show the sprints, etc. If you know/learn how to build a basic Gannt chart in MS Project or a spreadsheet - you'll probably blow him away!
Talk about resources - you might not need more generals but most projects can deliver better with more soldiers. Work with him to identify what resources you need. Also don't be afraid of bringing in outside help e.g. expert contractors, professional services, data processors, etc.
Tell him what the key blocks are - what Issues need to be resolved now.
Tell him what your concerns are for the rest of the project - what Risks have you identified.
For both the above - always consider the people issues, who are you concerned about? (the customer changing requirements, senior management killing the project, etc.). This is one massive area where PMs are there to help you - this is their key skill.
If you've done any financials on what the project is/will cost - definitely include these too.
If you talk through these things - any PM worth anything should be very impressed by your commitment and understanding of what's required to make the project a success. You should also be on a great start to your relationship - basically because you've given him all the tools he will need to do his job.
If things are going well, tell him you really want to be the architect/technical lead/head of development - what ever job title your looking for on the project. And if you need resources then ask if they can be report to you in some way (that includes contractors and SI resources, etc.)
Also ask if he can show you what a project or program manager does, learn the skills and perhaps get to attend some of his meetings with senior management.
You never know - you might like it and decide you want to be a project or program manager one day!
If you start something like this then you have every chance of both being very successful and delivering a great project for which you'll both be well recognised by your company, your customers and your suppliers.
Perhaps your PM will then move to another bigger project at the same or bigger & better company - then who do you think will be the 1st person he calls when he needs development help?
I've seen this many times in my career - not just on my own projects and programs but every successful project I've ever seen.
And finally, as PM - seeing your junior team members be successful is far, far, far more personally rewarding than delivering projects.
Good luck for your discussion with your PM and your project
Something I learned during an internship (Score:4, Insightful)
Pretend you don't understand and ask him questions. "I need to work with this team leader, can you explain his role please?" "I need to know what I can and can't ask of this consultant, can you clarify his mandate?"
He'll either give rational logical answers - in which case you can accept them or counter with more questions - or by trying to answer your questions he'll realize his reasons for doing all those things weren't as great as they first seemed to him - in which case you win - or he's a politician and changing his mind is flip flopping, so he'll dig in and defend himself at all costs - in which case you're screwed, but if that's the case you're screwed regardless.
Stop dating PM...you're not ready for relationship (Score:2, Insightful)
Refocus on requirements, refine the ' engine' core to the technology and relaunch when it won't matter how badly a PM fucks up the implementation, rollout and rampup......the core engine is defined, stable and sufficiently abstracted to weather the educated PM who's fancy certification and cadre of developers are deadset on changing the world.
Stars will shine......black holes will consume huge quantities of both manpower and resources but the core technology remains to power through...you will be vindicated, recognized and rewarded.
PM's then will do whatever you want.....you GURU WARRIOR you
Re:QA budget suckers (Score:3, Insightful)
This is what killed our company.
When we were a bunch of cowboy coders, it was chaotic, but we knew what individuals could get things done, and what interactions had to take place to get shit out the door.
Then we hired a bunch of agilistas, and in order to make sure that the "individuals and interactions" were properly reflected on the burndown charts, the MBA types demanded that we spend more time tracking our work than doing it. They called it being responsive to change, the agilistas lapped it up (and continued to work in spite of the MBA types), and the rest of us ended up quitting.
Re: solve your problem small (Score:5, Insightful)
I agreed with all the parent posts. Don't escalate without having discussed it with the program manager.
See it from their perspective, they also want what is best for the project. They want to ensure the project is on time and on budget... and a success. So you need to explain how your approach is better and how it will lead to a successful approach. A program manager will often do this because they don't understand the product/solution being developed. So explain what a good set up would be and why, and include examples of where this has worked for you before.
Also be aware that you may not get your way. Create a strategy for this situation. Ensure that you are in a position lead the technical piece. Ensure you have your ass covered when the shit hits the fan due to the PMs approach by documenting your approach.
First I would take the verbal approach with the PM. They may take a lot of talking to. Then if you think you have resistance follow up with and email. The email does not need to be pages, just short and sweet. Explain your position with 3 or 4 points, and how it would lead to a successful project.
Re:Don't go above your manager (Score:2, Insightful)
Usually this is how it goes:
You try to go to upper management, and no matter how good your stuff is, even if you can break up the problem into Powerpoint slides and charts with a large pop quotient, the higher-ups promptly tell you to stop trying to go above your PHB's head, and then notify the PHB about the attempt.
Things will only go downhill from there. Middle management tends to not be able to do much, but they can hold their jobs, and they are extremely adept at firing people, because there is always the uber-cheap H-1B that is their Holy Grail. Trust me, if there is one thing they are good at, it is lying, and because they are the only ones who see how the technical people are functioning, their word is law.
Best bet is to either tell the PHB why all the added people are not necessary, or if that isn't the case, start updating your resume and be ready to jump, since we all know how the coda plays.
The Ant Fable (Score:5, Insightful)
Print copies of this fable for the break room and make sure your boss and the project manager read it.
http://www.slideshare.net/faisalkhadia/the-ant-fable [slideshare.net]
This is gold!
Re:As A Boss... (Score:5, Insightful)
<sigh />
WHATevah...
You guys have absolutely no clue at all. It's amazing how we project these cartoon personalities onto others. That's what I mean about our "digital avatar" culture.
And yes, I am the boss, but I also have a boss, and they have a boss, etc. ad nauseam. I'm fairly low down on the food chain, and don't really have any ambitions to go higher. I'm extremely happy where I am.
HINT: It's really not a good move to have a knee-jerk reaction to authority, once you leave High School. As a manager for almost twenty years, I've learned the other side of that coin. I think a lot of managers go through their careers scared half to death. I think we make very bad decisions when we are scared. That's one reason I'm not in a huge hurry to travel up the food chain.
I have to eat poop, once in a while, but I have learned that my boss has to do it even more than I.
It's a very, very good idea to learn empathy. I see very little of it displayed in the posts, here, and that means that many of us don't play well with others.
In today's world, very few individuals make the product. Pretty much everything is made by teams. These teams are comprised of these annoying things called "other people."
We can choose to project cartoon-simple avatars onto these folks, and suffer the inevitable results when the real person won't fit the avatar, or we can actually try to figure out and understand these other people.
That doesn't mean that we need to accept and co-sign their crap. Our (American) culture has an unfortunate propensity to equate "understanding" with "condoning."
Big mistake.
If you want to learn basic things about rats, talk to an exterminator.
Here's my advice, as a manager... (Score:4, Insightful)
Your program manager probably wants this project to succeed as much as you do. Keep that in mind.
Be mature and communicate with them. Tell them your concerns, something like "This project is very important professionally and personally to me, and I want to work with you to make sure that it succeeds. However, I'm concerned that bringing in new team leads and consultants be done in a way that most improves the project. We've all heard the stories of new people being added to a project and causing problems . So how can we work together to make sure that this is a success."
Keep away from phrasing that is too accusatory, stay more neutral like I have above. For example, I said that I was concerned about new team members being the most successful, rather than saying "I am concerned about the new people you are bringing in will cause problems". Also, try to work with the program manager rather than being sure that they're just going to wreck things and you are the only hope.
If your program manager is any good, you can almost certainly accomplish more together than either of you can apart. Remember that and work together.
Sean
PM is right until you're done this (Score:5, Insightful)
Re:Steve Jobs? (Score:2, Insightful)
No, Steve Jobs was no engineer - but he had vision, and knew how to get his engineers to buy into that vision.
He was a lousy manager from Apple's inception, and it bit him in the ass. He had to learn how to manage effectively to get the results he wanted. And get them he did, so don't dismiss him lightly. He had qualities that were unique, valuable, and unquantifiable.
The problem is, managers are not there to pull wheat from the chaff and elevate people to positions of power. They are there to keep people in line while shining up their own resumes.
Re:solve your problem small (Score:2, Insightful)
Invite your PM out for a coffee break or lunch break offsite once a week. You don't have to talk about work, but do talk about non technical interests and null value stuff like sports (Nothing from your personal life). Your PM does not understand the tech and cannot relate to you so you must give him/her a warm fuzzy feeling so he/she does not need to hire the security blanket (er team leaders and consultants).
Don't sabotage your opportunity! (Score:5, Insightful)
If the project has momentum then the absolute worst thing that you can do is resist adding additional people to the project. If you do not understand how additional people can increase project velocity and add value then you are not experienced enough to make that decision and it will show to all of management. What you need to do is be strategic about how the team grows.
First you need to think deeply about what you do not know. What are the organizational hurdles you are likely to face? At what stages of the project will you be over-allocated as a resource? How many presentations and one-on-one conversation will be necessary keep momentum? How will this project be monetized? How will the end product integrated into an existing offering? Or how will the end product be marketed and sold?
Once you have a good inventory of what you will need, sit down with management and talk about how to address these needs--this alone will earn you a lot of respect. Ask who will likely be assigned to the project. Start taking these people out to lunch to discuss the project. If they are more senior they will generally offer to pay. Don't hesitate to pay even if out of your own pocket. It will show how committed you are to the project and organization. During these lunches ask questions about the process other successful projects have gone through and the types of problems your project is likely to face. NOTE, it is critical to not be defensive or offer too many pre-baked solutions during these meetings--it will come of arrogant, dismissive and impulsive. It is much better to say things such as, "I have some thoughts around this, but need to vet the ideas with people who can really help shape them." You will have opportunities to solve the problem in due time, or even better to have other people "solve the problems" with your solutions.
Ask if you can be a part of the decision making process for attaching additional people to the project. If you are included, be very judicious using any perceived veto power. It is better to raise concerns and shape involvement than to try to establish a front. Of course, there are always cases where lines should be drawn, but if you have voiced realistic concerns then you can keep management up to date if you seen things going awry. If you are not included, accept that decision maturely and remain engage in the process. You will likely have more influence on the side lines than you realize.
As the project grows you will need to find an exit from your technical role. You will need to own the vision, but you will not have time to execute all the technical details. Mentor people to take over the details and build as many documented repeatable processes as possible.
Learn how to present your ideas. You will likely be invited to more presentations. Know your place in these presentations. You have more to lose than gain if you say too much. Be there as the "guru with upside" instead of being the "one-hit wonder" or the "wild card."
Good luck! I hope you do well. Don't be afraid of not knowing something. Nobody knows everything. Embrace other people's capabilities especially when you don't understand what they do or who they can help. These are generally the people you really need.
Lone wolf vs planification (Score:5, Insightful)
This hat might not fit, but I am compelled to present you with this anti-pattern.
I've work for 8 years with a visionary guy who could come up with incredible prototypes in 3-6 months. And you know how prototypes become the product. We started working on a 2-3 years project and he would feed us tasks as needed. It worked well the first year.
Then the team grew to 5ish and he couldn't feed us enough: he could not develop his architectural ideas without delving in and thinking code. Documentation, comments, planning were anathema to him and he never mastered the art of leading large teams.
Now we're going through this prototype, implementing modules which work just enough to show what should be there but there's no intent visible, no idea if it was a first draft or if that way was necessary for some other reason. At least what is done is well done, which is an improvement to the other lone-wolves that I worked with in my carrer.
That might be what the manager rightly fears. Just as you have to brainstorm with him what will be the role of everyone in the team he's building, you need others to brainstorm, and document, and plan, how the pieces of your software will work together. I know they're consultants, but try to learn from them how to do more than code rather than fear the loss of control.
Re:"don't do that, it's ..." (Score:4, Insightful)
I'll say you had a good first phrase that can be useful.
Managers rely on the tech team to know what not to do. The mistake in "don't do that, it's idiotic" is that the last word suddenly makes it Ad Hominem. It stops being informative and becomes an attack. "Don't do that, it (making up something here, don't hurt me) interferes with the nightly backup integrity which means you might not be able log onto the system at all if any other glitch happens" is informative. With a few minutes to think they can realize that's a Bad Thing. Bad Things cost money. So maybe a rule of thumb is to avoid Adverbs. If you find a sentence about to end in an Adverb, maybe replace it with an extended noun clause. I know, all fancy English grammar, but a Factoid is what it is, that's what the techies do. Adverbs are judgemental.
Re: solve your problem small (Score:4, Insightful)
Parent is close -- except for the assumption that the PM wants what's best for the project -- the PM wants what's best for the PM's career; one of your jobs is to figure out how to make success of the project support the PM's goals.
Re:As A Boss... (Score:5, Insightful)
It happens everywhere, but it impacts us the most when we are in conflict. I could certainly point to any one of a dozen current front-page stories (and the horrifying series of comments that inevitably follow), for examples. See my .sig for why we tend to choose simple, binary answers to all our problems.
The only thing I can say is "So, how's that working out for ya?"
Say that there's a tech writer that has a kid at home that needs to be picked up from day care ($500/month) at exactly 6PM, or they start racking up serious charges from the poor schlubs that need to hang onto the kid past closing time. This is an extremely common scenario. Let's say this tech writer (either male or female) is a single parent (for whatever reason).
This tech writer works with a crew of amped-up, high-capability programmers; all male, all just out of college, and all absolutely soaked in their jobs. They have stock options, make big salaries and have an extremely dynamic, cohesive team. They tend to pull "all-nighters." Basically, the kind of folks that employers love to have working for them.
Now, you can probably see some conflict coming down the road already...
This tech writer needs to have meetings with these programmers.
The programmers tend to want to have meetings late. Say 5PM or later. Some of them don't get in until 2PM, and they like to have subs and calzones at their meetings.
The tech writer needs to meet with them to get specifics for the docs. They insist that the tech writer meet with them at 5PM or later.
See where this is going?
Now, of course, the tech writer needs to either decline the meeting, pay out the nose for extended care, or have very, very short meetings.
When the boss asks why the manual isn't done, what do you think will happen?
If the boss is any good, they'll understand the tech writer's plight, but they may still be in a quandary. If they start insisting that the programmers (who are blissfully unaware of the tech writer's plight -they only think that [s]he's a "whiner," or "lazy") make arrangements to suit the tech writer's schedule, then they risk generating team friction. The programmers may start to resent the tech writer, and actually start making life difficult for them.
Or, the programmers might develop some empathy for the tech writer, and start making some accommodations. Maybe one or two of the "early birds" could meet with the tech writer at more reasonable times, with input from the "bedbugs."
The final solution may be that this particular tech writer may not be able to work with this particular team of programmers, or the programmers might start to learn about things that are more important than stock options and sixteen-hour-days; like kids (If folks have yet to have kids, then they haven't learned the TRUE meaning of "priorities" yet).
However, this seldom needs to be the case.
One of the things that I need to do, as a manager, is manage each team member from a perspective of empathy; not coddling or condoning.
The tech writer may, indeed, be a whiner, and may, indeed, take advantage of the fact they are a single parent to demand unreasonable accommodation. However, here's where that "mile in their shoes" thing comes into play. I need to see this behavior, and hold fast on the company line, yet also find where I can accommodate them, help them to feel as if someone understands them. I won't coddle anyone, and my employees know damn well I can be a real bastard, if they choose confrontation. However, it rarely comes to that.
As a manager, my first duty is to the corporation. My second duty is to the team. I am responsible for ensuring that the team works as effectively as possible, which often plays to the first priority. However, I have to make sure that the organization's priorities are respected and maintained. This includes things like HR policies, ISO 9000 gates, working hours and environment, etc.
I have been given the authority to command people to make acco
Re:You seem a bit naive (Score:3, Insightful)
1) people must be made to do the work that everyone hates.
And that's exactly the problem with MBA types. They see jobs that they have to force people to do. .So they have to find ways of enslaving people without calling it slavery. ( Cause we know slavery is bad, so if we engage in it we can't call it that.) Furthermore they have to make people who will do it-- ie a social class to enslave.
Of course once they create the social class they have to find ways to keep the jobs around to employ these people they created to do the job in the first place!
The economist or engineer would look at it differently and the toilet cleaning example is a perfect example. Without creating a social class to do this jobs, you would have to find some people to do the work. Most likely younger people because they are hungrier. If the job is really distasteful then the salaries will be high.
To the MBA, keeping salaries low is a reason to create a slave class, as I detailed above. To an economist or engineer, it will create pressure to create easier to clean toilets and machines to that can do most of the work of cleaning toilets. Probably be a ex-toilet-cleaners and their supervisors.
To sum up the MBA sees toilet cleaning as an opportunity to hire people to build up his little fiefdom. The intelligent part of society sees it as a place where inovation is needed to improve the quality of life.
Re:As A Boss... (Score:4, Insightful)
Many times there is simply nothing you can do. In a large corporate setting - very rarely will you see excellence. Instead mediocrity will be the norm for various reasons:
1. Processes and organizational silos get in the way of performance. It doesn't matter how much you warn the design team about the problem their design has with battery life of the gadget in question - they almost always have the 'not designed here' mentality that negates outside suggestions - since they are in a different group and don't report through your chain of command. Sometimes the process itself forces bad implementation and deployment - either in time, costs or both (e.g. time to market window is missed because we had to wait for all the boxes to be checked in the process - thus losing out to a faster competitor).
2. Programmer resources are seen as interchangeable widgets. We all know this is not true - but management thinks so and allocates resources accordingly - which generally results in non-optimal results.
3. IT is run and managed as a cost center - driven by accounting. This means the focus is on cost rather than results. If the results are 'good enough' at a given cost point, then that is okay with management (too bad for the poor people in the operations teams who have to actually run and troubleshoot it in production). This drives downsizing, and outsourcing too - driving good developers either out or up (into the peter principle area - which causes still more problems).
4. Upper management politics. Turf wars, empire building, whatever you want to call it - can put a damper on any project as the upper managers jostle for projects and resources. You can also see similar effects when upper management doesn't know what to do - projects without clear benefit become hot potatoes - or focus is lost altogether. This is when you get really bad 'designed by committee' projects that usually end in disaster.
I've experienced all that and more in my 16 years in the business. That experience has proved invaluable in my own projects - not only knowing what problems to anticipate, but also knowing how best to allocate the people and resources I do have control over - at least until the next reorganization takes them away.
My advise would be to remain flexible and valuable. Be able to roll with the punches and keep upbeat - but be sure to do what is in the best interests of your company - you can never be seen as negatively disruptive if you are doing what's right for the company - and be able to express that to your management chain in a positive light. Learn all you can about your craft and the jobs of those on a typical development team from inception to deployment into production - know the pitfalls and how it all works together (or should if it is dysfunctional). Do what you can to mitigate problems - before they can damage the project or the company's reputation, but pick your battles - you're not going to be able to win every time. There is no use being scared; whatever 'security' exists in a large company is a fallacy that only exists as long as the next reorganization and can be impacted by financial considerations outside of any value you might bring - assume the worst and be happy when they decide to keep you around until the next one.
Finally, if that is too difficult to manage - start looking for work elsewhere, for your own sake - in a small company where these kinds of issues aren't likely to happen.
Re:PM is right until you're done this (Score:2, Insightful)
What if their motivation is, and this has happened to me, that doing this will increase the number of people reporting to them ? In my experience it will often do so, even if the project fails. Project managers are not rewarded according to success/failure but according to how much they are in favor higher up in the organization.
(I worked at a bank previously)
I've yet to meet the first PM that knows what their job is. There is this assumption among managers that managing network outages or managing software development is really the same thing. In a management meeting, I once directly said so, assuming everyone would see the sarcasm, but instead everyone agreed. The projects that worked had a developer (or in one case, an architect) "manage" the PM, which essentially meant sending him bullshit -but reassuring- messages from time to time. I've been doing it ever since. Keep them away from developers at all costs.
Keeping track of field engineers would be a good PM job. Know any network PM that does that ? Keeping track of programmer's assignments on different parts of the codebase and analysing bug lists to come up with proposals for improving certain parts of the program would be good for a PM to do. Again, have you ever known a PM to do that ?