Why project managers get no respect
There is not a child who dreams of being a project manager. Maybe a firefighter, a rock star or an astronaut, but a manager of projects? There’s something inherently dull about the words “project” and “manager.” They’re not terms that come to mind when people dream about future careers. And it follows that in the professional world saying you are a project manager won’t get you much respect either. To many being a PM means you fit this unfortunate stereotype: you were not good enough in your field to be an engineer or ambitious enough to start a company, and through politics and self-inflation, you find ways to take credit for the hard work done by others. It stings, but that’s the sometimes well earned stereotype.
Many PMs unintentionally reinforce this view by trying to get everyone to pay attention to the work they do produce: the meta work of spreadsheets, specifications, presentations and status reports, failing to realize that to most in any organization, these are the least interesting and most bureaucratic things produced in the building. This mismatch of value sends the PM and his/her team into a downward spiral: the PM asking for more and more respect in ways guaranteed to push people further away.
The core problem is perspective. Our culture does not think of movie directors, executive chefs, astronauts, brain surgeons, or rock stars as project managers, despite the fact that much of what these respected professions do is manage projects. Everything is a project. The difference is these individuals would never describe themselves primarily as project managers. They’d describe themselves as directors, architects or rock stars first, and as a projects manager or team leaders second. They are committed first to the output, not the process. And the perspective many PMs have is the opposite: they are committed first to the process, and their status in the process, not the results.
The result is that most of the world thinks of project management as BORING. Not sure how it happened, but instead of thinking of the great moments in PM history, say the NASA space race, The construction of the pyramids, the Empire State building, the production of every great movie, or any of a thousand great things made possible only by someone’s effective management of the project, people think of overdesigned presentations, epic status reports, and people who spend too much time creating meetings. If you are not going out of your way to separate yourself from the stereotype, odds are good that when you say “I’m a project manager” the person you are talking to puts you into a Dilbert cartoon in their mind, and you are the punchline.
People with job titles like “Program Manager”, “Product Manager”, “Information Architect” or “Quality Assurance manager” have similar problems. These titles all makes it hard to relate to what it really is that the person gets paid to make happen: a sure sign of title inflation, confusion via over-specialization, or abstraction from the real work. I suspect all of these folks have similar problems with getting respect from people when they introduce themselves with their literal job title (process), instead of what it is they help make (better results).
The news isn’t all bad. This lack of respect creates a huge opportunity for people with open minds. First, their expectations of you are low. Second, most projects are a mess in one or more ways. If you can provide clarity and sanity it will be noticed and you will earn more trust and authority. If put your focus on your teammates, asking how you can help reduce their frustrations and making that happen, they’ll return the favor. You’ll get more respect than you expect. And you may find that people start referring to you as a different kind of PM – one who has changed their opinion of what a good PM can do.
See Making Things Happen, my bestselling book on how to be a great project manager.
Amen, brother. And I say this as a programmer, not a PM – I tried PM, hated it and was terrible at it. Dear Lord, send us more PM’s like this.
This is just a general comment about project management.
This is more of a business management field than it is an engineering or other type of field. It seems like concepts are already discussed in other types of business courses are just reiterated in pm, even though I haven’t taken a course init. People stream away from engineering and other “noble” professions because other people did them growing up or to stay away from the people that took them.
This is just another management field to feel more confident in an executive role that requires communication skills rather than engineering skills. People need to stop talking like doers or engineers all the time and talk like humans. I’ve never seen an arts major get back into an engineering field, but engineers certainly try to get into the business fields. I think engineers should feel threatened by managers because they don’t know how lucky and cheap they are.
Ale
I’ve heard project management described as accounting minus the dollars plus man hours and tasks. That’s probably where the boring comes in.
Nevertheless, and honestly now – how many programmers are really working on something that is not fundamentally boring for a paycheck? Is it any more exciting to work on fuel nozzle velocity dynamics than to be managing that project?
I think some people actually consider writing Java middleware for financial institutions to be exciting, but for each one there’s a project manager who also thinks his job is something special.
Plus, I think the pyramids are not a good example of great project management. Great empire building maybe, but slave labor plays havoc with efficiency and resource consumption constraints.
Here is my biggest problem with most PMs, from my limited experience in the industry as a developer. Most PMs try to lead a team to project completion, rather than help the team. As in, the manager will tell this developer to work on this subsystem, or finish a given spec sheet, or whatever. Engineers tend to know how they can best use their skills (and other team members’ skills) to implement a project. This leads to conflicts between developers, and lambasting of the management.
The best manager I’d ever had on a project left the few engineers on the project to divvy up the work according to their strengths and timelines, and remained on the project to figure out the answers to questions from the developers.
Someone once told me that I would be a good project manager, so I read a textbook about the field and asked around. It sounded like the worst white-collar job on the planet. No thank you.
Thanks for the great article, I just wanted to point out that the role of the PM has changed drastically from what it was 15 years ago with the advent of agile methodologies. I believe (and I may be totally wrong) that many of the smaller code shops are having good success with the manager stepping out of the director role and more into the scrum master role.
The days of MS project where each developer was daily allocated 35% to this project, 55% to that one, and 60% to yet another ( I know it doesn’t add up) are for the most part behind us..
As for the “traditional” PM role being boring..
Coders (to which I am one) are not stupid, when you see a guy spend 2 days a week from 9-5 in a boardroom with other suits, there is no box of donuts big enough to make those meetings any less excruciating. Especially those “pass the buck ones” on missed launch dates. To make it worse, just stick the PM on a 2 hour teleconference with his offshore shop at the oddest times of day or even better, whisk them off on a red-eye flight for a next day meeting. The word is “hell”, not “boring”!
Lastly, any PM that isn’t a micro-manager and is a team player will be supported if and when the shit hits the fan.
Thanks again for the great article.. great read
ilan berci
I partialy agree…I’m a sw-dev/architect and I think I won’t be ineterested in becoming a PM (at least in the next 5 years). Anyway I think the big issue is that for almost all the small-company-bosses with no experience in programming there’s no difference between a PM and a Technical Leader. What do they need? A PM? A TechLeader? And this is bad…
Most PMs get no respect because they took the job to make more money. They show no interest in learning how to do the job well.
I go way back to a story written by Jerry Weinberg in one of his books. He was a programmer and had a stressful home life. He wanted to become a manager so he could make more money and hire a housekeeper to reduce the stress at home. He then realized that his home life was stressful because he was a lousy manager at home. If he was lousy at managing a home, why would he be any better at managing at work.
He remained a programmer.
Dwayne: That might be true, but if we’re going to criticize people for taking jobs that earn them more money, we’d be criticizing a large percentage of people. Frankly, if bad PMs are the norm in any organization the problem isn’t the PMs, it’s whoever is responsible for hiring them.
Ilan: There is something to be said for being the guy who takes “boring meeting” bullet for the team. If the PM can be in the room and prevent stupid decisions from happening, while allowing the programmers to do what they love, which is to write code, the have a great deal of value to those programmers.
Just got my PMP… you guys are depressing me =)=)
I’ll try and keep the dev’s perspective in mind, I promise =)
I don’t have the PMP yet. I only have CAPM. But i have had the PM role for two years now. I wish I could go back to grunt coder. PM is the worst white collar job there is. It is hell on earth. Add on top of that that because of my now crazy meeting times and shitty flights my wife also hates my job. So in summary: if you’re a good coder, stick to it and don’t ruin your life by becoming a PM.
Amen! One of the truest write-ups I’ve ever read on the fate and state of PMs. Especially true in the software industry
I think PM’s aren’t respect because they focus too much on process/procedures over leadership. As a PM, or any job title, you control your destiny. You can LEAD the project or enforce meetings and procedures. If PM’s would focus more on the people involved in their projects over the process maybe they would get more respect.
I’m not the biggest fan of certain PM’s myself, but to be fair you need to step inside the shoes of the PM.
PM’s # 1 job is to deliver value. The rest is secondary. I’m not saying the secondary is unimportant(leadership, team welfare etc) but once you realize what their #1 is, it’s easier to see where they are coming from. I think not everyone looks at it from his / her shoes.
Great article. It made me smile. I am a PM and yes, this article stung a bit, but I realized I’m doing much more for my team than this article outlines. PMs who act as the first point of contact for their projects and field initial questions about status, defects, etc. are valuable. I act as a shield for my developers so that they aren’t in meetings all day and don’t have to answer calls with requests for additional changes to requirements.
Lisa: I totally agree. You used a key word – value. Value as defined by the other people working on the project. As long as the work the PM does is seen as valuable, and a net plus, by the actual project team members, they deserve respect.
The problem is I can think of a single book, course, certificate, or degree around project management that centers on this view.
And I’d go further – shielding is the first level, but higher levels of value include leadership, crisis management, planning, cross-discipline decision making, and on it goes.
Its easy to see the need for PM when projects are handed to inexperienced PMs, that are really technical leads of their area of expertise, that have little or no training running projects. These projects usually run late, over budget, or under quality.
The devs/engs can always blame everyone else – I mean heck, its not their fault that marketing didn’t describe the requirements in enough detail and they had to redo most of the work.
Enter the PM – the savior to this problem. He is the ring leader, orchestrating the project, taking full responsibility. Bad wrap? Ug, well, remember the days of failing projects – where everyone is running around like chickens with their heads cut off.
Because most of them have not managed to earn it…
Hi,
A very nice post. My personal feeling about PMs who’ve made it their calling, may need some personal counseling to have to put up with the crap day-in-and-day-out :).
For some of the respondents, I’d be curious how they’d feel about “accidental project managers” which for those in the IT side of things, most are. It’s not like the construction industry for example, where project management is a recognized and respect professional choice. Most IT guys doing PM work got there because they got the short end of the straw so to speak or they really didn’t know what they got into when they accepted the mission to work “miracles” :).
Project management by process is lack of PM maturity and it takes a lot of practice and learning from failures to improve one’s PM skills. PM’ing doesn’t come naturally IMHO because most people get by by following process (i.e. be a good corporate ‘team player’) than delivering results/outcomes.
Thanks for this article!
-Lui
You think PM’s have it bad, try being a talented QA Engineer. At least PM’s have some authority and input on direction. The problem is not PM’s or QA Engineers, or anyone else in the Engineering department who is not a developer. The problem is the developer. Somewhere along the way someone told each and every single software developer that they were God. That they were the best and that what they did was the most important thing in the world. Then they told them it was ok to be a complete social reject and to be as lazy as humanly possible.
The funny thing is that ALL of them took this advice to be true and actually live it out on a daily basis wreaking havoc on the entire team.
That is so true. We live in a tech culture where developers think high of themselves, are obnoxious to everyone around, and gang up on non developers. I can tell you this from 10 years experience in the industry in different jobs and levels. At the root of the problem are low self-esteem and individual frustrations of people who aren’t just good enough to setup their own tech company. PMs are just an easy target because they represent authority. Agile is just another way to sell project management to an increasingly individualist society (good PMs are doing the good stuff out of Agile already).
Sadly this is true at all levels of the organisation and you always get a scapegoat in any team. The difference is that regardless of their skills the role of a PM is to be accountable for delivering a project and therefore are easy targets.
Of course – Lord Sugar’s pretend project managers crews didn’t help to put a good spin on the role. It is very unlikely this is going to change.
If software developers are too lazy and weak to form their own companies, its good for project managers – startups don’t hire projects managers and therefore if every developer were an entrepreneur, project managers would be on the streets picking up tin cans and washing windshields.
‘Lasy/weak’ is your own interpretation Andre and didn’t appear in the message above.
The key points were:
1) there is more to the web industry than developers. There are many others talented individuals who are critical to the success of businesses. They are – but not only – managers, designers, testers, marketing, sales, etc).
2) the successes of businesses come from a range of skills (traditionally represented by different individuals). It is possible that some developers have the large scale of skills to setup their own business (and free themselves of/gain the authority embodied by the management). But it’s just not true for most of them, hence the frustration. Here I’m assuming that frustration is the reason for being haughty toward other roles but who knows.
A little respect goes a long way and there is not skills set superior to others. Hard and Soft skills just don’t compare against each other and are complementary. This is about team spirit and creating products as a group. Unfortunately the facilitator of that group (scrum master, project manager, product owner) often becomes the easy target for the shortcomings of the team. Sad because most of them really like people and get a buzz from the team dynamic. A respectful team that is.
Good post Scott! I have been worried about Job Title problems for many years. If you are interested in another perspective – there is a guest post on “Job Title Inflation” posted on my blog – http://fearnoproject.com/2009/05/08/what%e2%80%99s-in-a-name%e2%80%94job-title-inflation-hits-project-management/.
LIke the BLOG – keep it up!
Bruce
Well, I can understand the genuine frustration behind this post, because simply the Project Management job has gotten some kind of bad reputation these days, I think that’s because a lot of people try to make the jump and leave their technical career and shift to PM.
Second, the reason a lot of PMs follow the process is that they can not get the outcome without the process, I can think here of a weak matrix environment!
Third, PMs get lost while executing the project, they simply think of the project delivery not the value to be delivered out of the project and here lies the problem and that’s why projects do fail! ( you can check my blog about more posts about why projects fail )
Don’t give up, be a different PM, that’s it, Thank you!
Your article and some of the responses act as if the job of the project manager is to make the team members’ lives easier. I also see complaints of micro-management. The entire PM methodology, no matter which one you are using, is indeed micro-management. The PM’s job isn’t to take the boring meeting bullet for the team. The PM’s job is to deliver the value of the project back to the organization on time and within budget. That value should deliver one of three things to the business that commissioned the project: increased revenue, lower costs, or compliance with governmental regulations.
I agree with your assertion that PM’s should define themselves by outcomes instead of process. However, the process by which the valued outcome is achieved is generally micro-management. If it weren’t needed then the all-knowing developers could simply figure out their own requirements, run the testing with the users, report on the progress of their coding to the primary stakeholders who are paying their paychecks, negotiate change requests and how that will affect the delivery, order the infrastructure and test systems to test their code on, haggle with the vendors to get the best prices, ride herd on the subcontractors who haven’t delivered on time… oh, I guess perhaps a PM does add some value after all.
I get tired of the prima donna attitude of the developers as well. I didn’t mean for this to turn negative, but as a PM, I have to say that I’ve been on the engineering side. I’ve learned that the colleges are pumping out great developers and with a flooded market, the price of development goes down. Seems like I’ve read that somewhere before. Hmmm.
Without people skills, nothing gets done. The Sales department still rules the organization. I take the advice to heart about being committed to the output instead of the process. When we can get that part right, we’ll all remember that we are part of the same team trying deliver value, grow the organization, and thus secure our paychecks by satisfying the ultimate customers. The PM’s do play a vital role, whether that role is respected or not.
Jane – Bad PM’s Micromanage, good PM’s (like me) listen to their team, and then raise their concerns to the stakeholders when they demand something to be delivered in an unrealistic timeframe. Prior to joining my current organisation, my CEO was heavily insistent on us using the Waterfall/Gaant chart approach to deliver projects, this ultimately lead to long long hours, and rushed work for the development team.
After I came board and taught the whole organisation agile, with the concept of measuring work rate to deliver a project in the contracted hours, everyone is a lot happier. Now the team does very little overtime, but are extremely efficient in the hours they work, which is what good project management is about.
Hence, forecasting deadlines is a lot more accurate. Every single developer I have managed, many were interns, have with my guidance become very good developers since I learn very quickly without getting hands on their capabilities and how to help them improve.
Once again, people on here bitching about PMs don’t understand how difficult it is. Trying to get your CEO or stakeholder’s to accept a different way of doing things, when they hold contrasting views for example is very hard. The reason why a lot of developers are terrible PM’s because they can’t handle the politics that comes with PMing, they don’t have the interpersonal and leadership skills to stamp their authority on a company. People are arguably a lot more complicated to deal with then a computer program from contrasting views.
I can’t say that everybody I’ve ever met in the software industry or the likes gives PMs little recognition. I’ve even met people who want to become PMs and recognize the talent it takes to get a project right.
That being said, people do like stereotypes, and PMs are no strangers to them. But as others have also noticed, the worse stereotype in the software industry is probably that of the QA! The “mind numb button clicking QA that’s not really an engineer at all”. It really is quite annoying.
I need your help folks.
I have been been offered a place to do Project Mgt at Westminster University and UCL; and Supply Chain Mgt at Brunel University.
I am torn between these two courses and need assistance.
Your inputs will be greatly appreciate.
Thanks,
King.
The one you find most interesting. Advice heard often and often ignored. You are far more likely to excel in something you enjoy.
“Project Management” is a complete hoax perpetrated by people that do not have the skills to do actual IT work but want to work in IT anyway. PMs: you are managing nothing, you are controlling nothing, we do not need you, you are bs artists, you are a joke, go away.
Agreed most PMs Do not have a strong technical background, Just because they read a bunch of tech magazines and use a Mac does not make them tech savvy. And the sad part is they know they suck in IT but they want to look technical and that’s when they jump into project management. They are practically glorified secretaries.
…but that “bs artist” PM your refer to is keeping me out of boring meetings all day so I can do what I love – programming!
I’ll be forever grateful to the PM who can respond to business-related, non-technical questions about the project simply so that I don’t have to. Not to mention reporting, or requirements gathering (sometimes), or a million other things I appreciate the help on.
So I agree with much of what you said, except for the “go away” part!
I strongly oppose both the statement that PM is boring and that PM’s are fakes.
I have been in IT for over 30 years, developed micro chips, computers, write assembler code in Hex, compilers for several programing languages, CASE tools, Application software, did quality assurance and build simulation systems. All the while – trying to co-ordinate my work with the work of everybody else who worked on the same project with me. I just wanted to make sure they get my results when they needed it and I get theirs when I needed them.
Without me doing that, most of my projects would have gone astray. That’s the way I became a PM for nearly every project I was on for the Past 25 years.
I always wanted a job where I could organise, plan and coordinate things and people, and rearrange things to be more effective and efficient. That’s essentially what the PM is doing.
I wonder how your projects would fear if you didn’t have someone who gives you and your colleges / team mates a direction and a plan to work against. Several of the developers I know don’t see get the bigger picture and have issues organising anything that involves more then 2 people.
Bit of a daft post Roger in that you offer no constructive rationale as to why PM’s should be such deluded souls. I would guess that you are probably continually frustrated by being asked your opinion and then ignored, or worse, never asked in the first place and then continually asked to ‘sort out the mess’.
Regardless. I have been a PM in title for 6 years, moving from various tech roles which I held for many years. If I see an issue with PM it’s more to do with education. In the UK Prince2 is king, but Prince2 only begins to make sense if the higher level MSP programme level work has been done correctly; more often than not it hasn’t.
I’m a PMP and as such have been brought up with the rationale of owning the project end to end, from concept through to final delivery. This entails far more than maintain a gantt chart – which to be honest it what most people think project management is; in reality that takes about 15% of a PM’s time and effort.
I am sure you are well p1ssed with bailing PM’s out, for my tuppence I don’t see the issue with PM. I see the issue in the sales and engagement process that all organisations seem to follow – fill the room with people who can sell a dream to the people who don’t have the ability to understand the potential pitfalls. It shouldn’t be any surprise that a significant number of IT project fail, nobody bothers to ask the people who need to use the thing until it’s too late – this isn’t a PM issue, its a social hierarchical issue.
Fully agree and I will add more. All these assh0les do is send out stupid emails asking for status, asking for status, asking for status, using various different words. They can’t appreciate or even understand or try to understand the technical challenges worked on by the engineer. All they care is whether or not timelines or met. If an ass kissing engineer produces crappy work that would result in a lot of performance issues later on for example, but meets the timelines well, he will be well appreciated. On the other hand if a non-ass kissing engineer detects that there is some potential for performance degradation, and incorporates changes for efficiency even when not asked for, and even though his change will prevent problems later on after shipping the product, yet the stupid PM won’t even try to understand what it is the guy is sweating his ass on, and will only still check for timelines.
The PM fills a critical role in a project. The reason why they get no respect is the skills involved with the PM are all non-technical therefore almost anyone can do it. Whether they can do a good job, bad job or mediocre job is a different story, but literally anyone can do it.
As a PM, I can see truth in all of the comments. I worked in the trenches of IT support, field engineering, business analyst, help desk as well as non IT work. I always found myself bridging the gaps between business strategy and solution delivery. Working as a PM in the IT field, respect with team is essential as you are a professional manager working with professionals. Setting expectations with clear, concise communication and defined goals/work packages creates ownership for every team member. We have to manage the changes and scope creep to provide stability to the team and maintain flexibility. Having fun is also an essential element of successful PM work.
As a BBA who trained my self to program I’ve played most roles on IT projects except project management. I just flat out say it. Most PMs are lazy. They don’t want to learn. They do the job for the money and the title. They want to delegate everything and do not try to understand. They are usually are not concerned with improving themselves or their project instead they are concerned with visibility and perception. In most cases they are in that rut where there is no where to go as far as being promoted so they slack and just make sure they look good to the people doing their review.
My favorite role is now being an independent contractor developer because this allows me to skip all the Management BS and do my job productively. In truth, software would get developed a lot more efficiently and productively if project managers could get all the team to understand what they are building. But most times, they don’t even know themselves. They don’t even know how to use the software. As a technical guy I’d say we could remove 80% of management and be more productive and efficient. There are just too many bodies between the customers and the developers. Too many teams. Their should be on manager for all these teams. Too many managers is chaotic and inefficient. They is WHY they get no respect because in most cases they are not needed on the project.
Twat
I am a PM and I have been in most of the roles in the SDLC. I have been in IT for over ten years. With that being said, let me try to help folks understand why PM’s are a necessary evil. And also, why you should be nicer to your PM, especially if they are half decent and understand wtf is going on.
1) We provide team leadership and help junior resources. We’ve been in your role before, and therefore we can provide feedback for the deliverables you produce where we see gaps.
2) We take it in the a$$ from multiple angles. IT leadership. Business leadership. Every fucking stakeholder you can imagine. We get yelled at, screamed at, etc. Remember the time that you didn’t give a flying fuck and decided to not get something done on time? Which oh by the way, you provided the estimate for and yes, I probably could have got it done in half the time it took you. Do you want to go in front of executives in the steering committee and explain why the project is late? These are not happy go lucky people and won’t pat you on the back when you start crying. They won’t bat an eyelash kicking you to the curb where you belong and then laugh about it
3) Remember that time your project manager told you to take a look at the project plan and provide feedback and you never did? And then when shit hits the fan, you start saying X, Y and Z are missing from the project plan? Guess who has to cover your ass. That’s right. Guess who has to spend time re-planning and figuring out creative options for still getting things delivered on-time and on-budget because of you.
4) Instead of acting like a twat and blaming a project manager for not remembering something for which you are in the weeds 100% of your day, remember that project managers are juggling multiple projects at the same time. I am juggling on average 5 to 10 projects that are all in-flight. Instead of rolling your eyes and thinking your project manager is incompetent, help them by getting them up to speed on your shit. Simple as that.
5) Do we like our jobs? No. Did we want to become project managers? No. We moved into this role because we were good at all the other roles that we were on, and people wanted us to move into this role because it is multi-faceted and entails an increasing level of responsibility and accountability. Something that you are ever so forgetful of, but oh so ironic because you don’t forget when happy hour is. We just as much want to move out of this fucking role into something more strategic but are paying our dues just like your paying your dues. Or are you forever going to sit there being a software engineer, or business analyst, or test monkey. Think about it. No seriously…THINK about it.
6) Yes we are process oriented because following a process ensures something gets done correctly. If everyone followed the process, then things wouldn’t fuck it. It’s because your ass decided to go rogue and move code into production that stakeholders are screaming that the website is down, and everyone is scrambling to fix a critical production outage. Oh and guess who’s taking it in the ass instead of you? What, your not a developer? How about those shitty requirements that you produced that took up probably less than 1% of your brainpower and you just parroted what the business told you and wrote it down with your shitty faced grin. Or those test scripts that you created that missed some pretty basic common sense scenarios. Or how about you architected a pretty dumb way of doing something and now everyone is building your shitty house?
7) Stop getting frustrated about scope changes. It’s not my fucking fault that the VP of IT wants to do shit differently. No shit the scope keeps changing. So fucking re-code your shit and stop complaining. And NO i cant help stop the scope from continually changing when its someone that high up. Why don’t you fucking go complain to them instead and tell me how it goes? So STFU and just do your fucking work. If you quit complaining and just did your job, then shit would actually get done
Now i realize there are a shit ton of shitty PM’s out there, more shameful, some of them are PMP certified and can’t PM themselves out of a paper bag. I’ve come across a whole slew of them, but if they are pretty good, stop being a bitch and give them some respect because we give respect and credit where its due as well
This made my day…thanks.
I have to agree with what was written above. The chains above all focus on the perspective from the development or project team. The key is the Business or Project Sponsor hires a PM for insurance, we provide visibility, we make sure the team doesn’t go off track, we’re there to hover like mothers to make sure that things coming at the project team make sense or if they don’t how to get in front of them. That is why PMs do a 360 around the team and look at it from every angle where it may appear like we hover or are running around it’s because we are trying to see it from all angles.
I think the key think is forgotten is that PMs work for the person sponsoring the project just like the rest of the team and the end goal is delivering a good product and if the team can’t deliver it together.. just know there is off the shelf that can be bought to meet the needs, my point is ALL the roles are important and ALL the roles can easily be replaced. Stop complaining when majority of developers would rather do anything that sit in meetings for hours going over the same thing but as PMs it’s the part of the job and we suck it up and do it as things developers or testers do, which personally I rather kill myself then test code, but it’s got to be done and there are highly train folks that do it. Again, in every role you have good and bad people. I’ve had shitty developers that I wouldn’t trust to power on a laptop as had horrible PMs that couldn’t figure out how to show up on time in the morning. This all needs to stop and articles that are written about this groups reputation or that groups only perpetuate the problem. My main point is grow up you’re all adults be ashamed of yourself and just do your contribution to the project or the product and stop worrying about “Role” reputation and just do your best and focus on your individual reputation not someone else. It’s the same message I tell my kids.
Exactly we need glorified secretary’s if there were no project managers around who would tell everybody that I’m out sick. Or keep asking me if we can do that or is that legal ? Lol also PMs tend to throw people under the bus to save their own skins, God forbid they don’t update their MS projects with the right milestones .
Want to know the reality of being a PM? You’re shit receptacle for all and sundry, from the CEO down to the lowliest intern everyone knows what your doing wrong and how you should fix it, I’ve never had so much good fucking advice since becoming a PM, some of it makes me wonder how I managed to find my way into work this morning, and of couse we only have your project to manage, it’s not like we are managing multiple projects with endless amouts of stakeholders and smartarsed ‘expert’s at every desk all running different technologies is it?
Do you honestly think PM’s would be needed, or indeed paid the salaries they get if the job was simply about creating a fucking Gantt chart and checking progress against it? Seriously, are you people so fucking dumb as to think that all the job entails?
It really fucking amuses me when some dipfuck developer / engineer rolls their eyes skyward because a PM doesnt know some detail of their ‘skill’ but it still beats me why if they’re such fucking experts they are incapable of providing a half accurate estimate to deliver against; anyone would think they have commitment issues.
Oh, and regardless of whether you are PM cerfied if you are a developer / engineer and PM’ing your project as well, your not a PM, you’re simply making sure your doing what you are supposed to. Fucking idiots.
The problem with some PM, mostly the ones without technical background, think they are the tech lead and want to run the show.
They demand constant report from the developers, blocking communication between tech teams, making stupid tech decisions, to show they are the one in charge, even they know nothing about technology.
So instead of shielding developers from meetings, they create more meetings, developers waste more time explaining solutions to PM, rather than focusing on delivering.
PM has its role, but they need to know their boundaries, they not the boss, and should NEVER be tech lead.
Sadly, there are loads of PMs in the IT industry who have never touched a line of code. I am extremely puzzled WHY this is the case – I come from a development and CS background, it would have been very very difficult for me to manage my dev team if I hadn’t. Some of the hardest decisions I have had to make were largely based around choosing the right technology with them and software architecture.
As a former commercial developer that is now a PM, I can say that Project Management is very tricky.
As a PM, I have to manage stakeholder expectations, manage my resources efficiently by delegating work to the right people as well as coaching/motivating my team. I also have to deliver projects on time and on budget, which means that I once I have organised my sprints, and the project has begun, I have to make sure that my team is on track through daily stand ups, retrospectives as well as writing well written user stories and user acceptance tests.
Outside of this, I have to develop a good understanding of what technologies are involved when delivering the project. I am not hands on in my role, but whenever I embark on a new project I actively help the dev team with choosing the right technologies, as well as helping them devise a good software architecture.
I think this article is very unfair in its assumption that PMs do not play an important role in delivering projects because they do not do the actual grunt work. The work we do is arguably harder for the reasons stated above.
“harder” LOL. and I am sure your pick of what technology developers should use takes heavy weight in the final decision made by senior developers and architects. — Thanks for adding evidence to the above article.
No, I generally let them decide, I just like to be involved in the process since it will help me understand what is technically involved.
As someone who has worked on many IT projects, I find little value in PMs.
They tend to be an overhead as they want to understand details, when they don’t need to know them. They like to control things, so it appears they have control. They want figures to present to the sponsor so it appears the project is going well, when the time it takes to gather these figures people in the project could be actually doing work. I’m sure there are some who are good but having encountered 30+ of them they’re all pretty much the same.
Well the PMs you worked with were basically useless. I was a commercial developer and after making the transition to becoming a PM, it is not as simple or irrelevent as you make it sound.
If you are an agile PM like I am, you have to make sure the productivity of your team is high and to do that, I have to monitor their progress using burn down charts, burn up release plans, cumulative flow diagrams to work out their velocity. I was recently in a situation for example where I was managing a remote subcontractor on a project that basically did little work for half of the project (this was before I introduced the reporting). It was only after looking at the CFM I had to get him back on track. The point is if nobody was managing him, the project would be severely delayed because he was coasting it – this is exactly why management exists to prevent this.
Outside of that to make the developer life easier, I have to ensure the functional spec document is properly broken down into well organised user stories, with the right story points attached to them.
Sure the developer can probably do this, but if he is in the middle of a sprint, do you think he will have the time to do this? Do you want him to do this work, or would rather have him write code? Especially if there are several projects to manage on the go? Do you also expect the developer to deal with client requests too? In every software build I have worked on, the client always tries to chuck additional features that goes beyond the spec, which can potentially lead to scope creep.
I am not saying that there are not bad PMs out there, often the good ones have good technical awareness like I have since I have spent time as a developer. Outside of that I actually spend a lot of time trying to manage the project correctly by motivating, improving existing processes so that projects are delivered smoother. But by making PM sound like a walk in the park it isn’t. If anything goes wrong the PM gets blamed. If projects are not delivered on time, it affects the company, since they are unable to invoice the client which affects cash flow.
I’d like to see a building or anything which is as complex go up if just left to an engineering team within a set budget. Everything takes funds to create. If it isn’t money then someones time which equates to money.
Truth is if you leave a team of engineers, designers, techs, auditors together guaranteed one will step up to manage all the activities as it gets confusing as the team members won’t go out of their domain of expertise to begin to stitch everyones work together. Plus when it comes time to inform the very person paying the bill, guaranteed they will be asked to report on status, that very person who stepped up will then begin to request status reports and aggregate to provide a high-level status to whomever is paying the bill.
That person is now automatically in the role of a PM.
Everyone plays a part including a pm. However a PM should trust their team & their specialities. PM’s that get into the nitty gritty details are those that are just doing it due to lack of trust.
For me it is always funny when I hear a project manager saying that he/she lets the team decide on technical issues. That’s because very often (almost all the times) the project manager is not the most experienced subject matter expert on the team (many times he is not a subject matter expert at all) so he simply has no other choice than letting the team (actually the technical leads) to decide on all the technical aspects.
I often hear project managers saying that they are empowering the team, giving the team members “authority” to decide, but in reality they (the project managers) lack the competence needed to take decisions of technical nature.
Probably many project managers don’t want to look dumb in front of the team members and instead of telling them that they are unable to take technical decisions they prefer to give the impression that they are actually giving the team higher responsibilities and the power to decide.
The reality is that most project managers always want to be in control but the fact they are not the best technical experts on their teams severely limits their ability to control the project team as they will not be able to give technical directions to the team members.
When there are better technical experts than the project manager or the project manager is not technical at all it is clear that the best subject matter experts on the team, and not the project manager, will take all the technical decisions.
You are missing the point of project management, the point of it is to help the team deliver the project on time and budget, not to be hands on with the code. Hence,it is much more heavily linked to operations as opposed to the technical side of a business. A PM might not be expected to write code, but they have to do a lot of administrative tasks – budgeting, resourcing (assembling the team for a project), QA, account management, internal and external reporting, keeping track of spirits (if running agile) using burndown charts/cumulative flow diagrams/resource management . In addition, if the project is going badly, the PM will be accountable not the developer.
A tech lead is exactly that, a tech lead, they are expected to know technical side inside out because that is their role, and very often they are the one’s doing the hands on dev work too – which is what they should be doing, not being involved in the operational side of a business.
For the record, I can code, have a computer science degree and spent time as a commercial developer. Having technical awareness helps, but the reason why I made the switch is because programming is a boring job where your life is coding a set of requirements as opposed to being involved in the bigger picture.
That is how it is supposed to work. Now if you are working on a huge global project I mean involving multi components from design, infrastructure and global implementation and major capital expenses your program and project manager would own you! You are a technical authority at best and though an important component to a project not the only one.
on such projects a project manager is engaged pre-sales at the bid stage and is often involved in bid management to workout costs and high level time plans. On such a project your line manager would understand that YOU report to project management for the duration of you allocation to a project. You may be a shared resource but in large projects you can also be a dedicated resource and you performance on that project evaluated by a PM can propel you in a corporate structure or see you dismissed.
Honestly, reading into what you stated shows me that you do not have such experience, your mind is simply technical.
One issue never covered is the over use and misuse of project management especially in the IT world. Just as there is more misapplied in vogue methodologies then properly applied. The PM who mentioned he was an Agile project manager is suspect to me. I have seen that applied to everything it should not be. I have seen it create more overhead for everyone. Issue is that Project managements management (got that) often is placating purely political whims and in turn requests all kinds of info from a PM and then the PM ends up actually interfering with project progress in order to gain the required info. Info that is often so dynamic that it is useless by the time it MIGHT be looked at. Most of these IT projects that have PM’s assigned need no PM. Only complicated engagements should be so managed. NON-Cookie cutter, high dollar Million +, with multi phases. Rollout of a repeatable deliverable at few hundred thousand per does not qualify! in addition the creation of a small e-commerce web site does not qualify, lead engineers can handle this. THIS IS THE PROBLEM.
Thanks Johnny for calling me ‘suspect’, admittedly I am not the most experienced agile PM since I have just started doing it, but I work hard to do my best in implementing agile in my company as a PM. I am also a certified scrum master.
From what I can tell you, when this company (a small organisation) didn’t have any one managing their in house product or other projects using a framework, they ran into the following problems:
1) Nobody to manage unrealistic stakeholder expectations. (big problem)
Developers would often be given unrealistic targets by the stakeholder i.e. You have 1 week to deliver 4 weeks amount of work not taking into account what is actually realistically possible, since velocity wasn’t tracked. This also was bad since it doesn’t work well with changing requirements.
2) When working on meeting a target, the developers would then be interrupted by change requests causing a lack of focus and rushed work as opposed to properly completing functionality one at a time and releasing the product in increments.
3) Poor quality work being delivered – rushed.
4) Developers who have to spend time doing administration work; internal reporting etc rather then focusing on writing code.
5) Nobody tracking productivity properly. I use burn down charts to do this based on the velocity of my team during weekly sprints.
6) Sales team taking on work with impossible time frames and lack of resources. Since coming into this role, I have told the sales team to think agile, that means not letting the customer disrupt sprints by asking for work to be done straight away, but to wait for the next sprint cycle before undergoing their work.
7) No QA process based on user acceptance criteria in user stories. Nobody to ensure that this was being done properly, previously developers were doing this, we now have a dedicated QA tester doing this.
etc etc etc
As a result of the above, the original product had to re-written by my team. It was no maintainable (very hard coded). The company now has a working product which scales.
As much as Project management is useful in large organisations for the reasons that you have mentioned – and I agree with them. In start ups or small organisations (the organisation I am working in), poor project management can lead to a poorly executed product which could cause the start up to fold. Telling your tech lead to project manage business critical builds, when resources are already extremely tight and you want him to code is going to slow delivery down.
I am a Project Manager. Prior to moving into project management I was first a .NET Developer and Solution Architect. I’ve implemented large enterprise systems for the Federal Government as a Developer, Architect and PM. In a pure product development environment, PM’s certainly have a reduced value; however it is now 2016 and the client service industry exploded years ago; in this world PM’s are beyond vital – more important than the rock star Architect on your team and now as a Director I would fire the Architect before the PM 99% of the time. As a PM, I was no doubt smarter than most of my Architects and can guarantee in client services the PM’s job was far more difficult and vital. Any technical experts that disagree, it’s simply because you are so short sited and buried in code that you think the world is made up of 1’s and 0’s – do yourself a favor, go thank your PM for inflated salary and growing job demand – he’s the one driving business for your company in a highly competitive market.
Agreed.
Making sure projects are delivered on time, with high profit margins affects cashflow and client retention. This does not require technical skills but business acumen if anything. The developers on here moaning, are as you say extremely short sighted and need to spend time delivering projects. By that, managing a cross functional team trying to keep everyone motivated and on track.
None of these arguments relate to technical systems installation on construction projects. Agile, scrum, sprint and others running for product, software and update development, force change construction and TI projects everyday. The needs of “product” launch blow construction projects continuously. Product development communities have no clue of there cost impact on construction.
@Bob, I don’t know about construction, but in digital that is not the case, on this thread many people are wrongfully assuming that all that is needed to deliver a digital project are developers. Ironically, that is probably why many of the developers on here won’t make good PMs, since they view the project lifecycle so narrowly.
Every serious digital project I have worked on has a cross functional team working on it, designers, developers, business analysts. At which point my role is to put processes in place so that work is delivered on time by each team to avoid bottlenecks. Some projects can become very complicated depending on the size of teams involved, or if you have 3rd party resources working on them sub contractors etc.
With that in mind, PMs are not there to do the technical work, rather they are a bridge between stakeholders and the different teams ensuring that time frames are respected and each team have what they need to complete their work.
So more to the point, all they care about is the ‘delivery PROCESS’, and helping the organisation ‘improve’ that PROCESS so that work is delivered on time and more importantly on budget. Agile is one way of setting up a project, but you then have others such as Prince 2, Waterfall etc. To do this successfully, requires a lot of organisational and soft skills, not technical. Using Agile methodologies for example, one of the key things I had to do at my organisation was to coach agile methodologies to C level and non technical/technical teams to ensure that it is being done properly in the project lifecycle. Without doing that, we often relapsed into a waterfall style of working since the sprints were not respected.
We are in very different areas of the PM arena. My background is also network design, engineering and business management as well as technical commercial construction so my experience in development and projects goes back many years . In my current area of focus our business requires the PM to be 100% financially responsible for the project(s), manage the resources of the project (s) and be the technical lead of the project. Regardless of any grievances employees might have it is the lack of understanding of a companies processes by all participants in a project that is the failure. This is the failure of company upper management itself, not the PM, technical lead or developer. Lack of training in the most efficient and effective company processes and in communications in order to effectively complete projects for all must be gained and paid for in advance. The pressure of time, cost and resources required for project delivery remains completely misunderstood, wasteful, inefficient and very expensive in general in the business community today.
More often than not in my business the failure is not at the PM level but at the technical resource and company management level. I have years of examples dating back to the late 70’s and early 80’s with commercial and government projects to prove it and it still is pervasive today. I am a former design consultant and business owner and did not allow my employees to be poorly trained and deliver projects inefficiently and with cost overruns. The problem is not with the life cycle of the project but with the failures of the owners and the upper management of the business.
@Bob
Our industries are different, so maybe it works differently where you are.
In IT, don’t get me wrong, having technical awareness is not going to hurt you as a PM. If anything, I do recommend that all PMs make an effort to gain that knowledge since it is then harder for your developers to bullshit you when making estimates. With that said, I do feel that it is overestimated at what level you need to be technically, because chances are even if you do come from that background and move into a hands off PM role, you are going to experience some degree of technical decay anyway – technologies will change, and more importantly you may not always manage projects where you are technically trained in especially in agency environments.
Furthermore, even if you are technical, there are skills as I said before that are needed to deliver a project outside of technical skills, every product uses designers for example, who create wirefames, prototypes and are skilled in illustrator, and photoshop. By your logic, does that mean the PM needs to be both a developer and designer in order to successfully deliver the project? Yes, it would be nice, but it is not realistic since these are two separate career paths.
The whole point of PM is to get the right resources and to put processes in to deliver a project in a structured way. In very small teams, a PM is not that important, but if you have a cross-functional large team that’s where it is definently needed. Without structure or good processes in place to get teams from different departments to work together, there will be delays, and the project will go overbudget.
The author didn’t say PMs weren’t important, rather that they get no respect. What he did say is that PMs often go out of their way to show they are important, like you did in your response, which gives the PM less respect.
@MsBOB
I did go out of my way, because frankly I have found half of the comments offensive and undermine the work that I do.
Not because I’m insecure about the value I bring to a company, but because the work I do is incredibly stressful from managing stakeholder expectations and trying to keep my team on track! Having clients shout at you because work is not being delivered at the speed they want is one example of the shit a project manager goes through which ‘happy go lucky’ developers don’t have to worry about and why they should be respected from being a human punch bag.
This whole thread post is deeply offensive to the whole PM profession.
As a developer with 10 years experience my opinion of PM’s is simple: I can do their job but they can’t do mine.
As a Principal Software Engineer with nearly 30 years of experience, my opinion of PMs is very similar. In fact, I do their job as well as my job. They only know how to ask for a status, quite literally nothing more.
As a Senior VP who in essence, is a program manager for multi million dollar portfolios, this is the thought process of most developers; thinking they can manage people when it’s most often times much more complex than managing software solutions.
Fallacy of engineers in their tech bubble.
I agree with this wholeheartly. I too am a technical PM. I am lucky because I have a technical background (I was a BRO) which commands respect from my colleagues as well as the engineers I work with. Only this week our best technial engineers had an issue with WIFI that they could not fix. They asked me to cast my eye over the problem and the issue was resolved within minutes. I also fixed the broadband at Glandwr House. There is no member of staff at my workplace that is in any doubt of my talents. I appreciate there are some bad PMs out there too though, I guess it’s the same with any job…
Just to summarize, project managers are essential to any project and they play a critical role in delivering projects on time and on budget. The best type of power project managers can use according to PMI is the Expert power ! If you have knowledge in the field, you will get the most respect from your team.
It’s funny sometimes to see job descriptions where employers search for candidates with degrees in journalism or communication !!. Even project managers spend 90% of their time on communication I believe that having a technical background would add extra respect and improve cooperation with your team which is a key to success.
If they do budgeting, why do they put their nose into calibrating employees? Huh? What do they know? Really, what do they know?
A majority of the PMs i work with don’t understand anything about the projects they manage. They put in the minimal hours. They take vacations during critical deadlines and are hardly ever available to answer questions about their projects nor resolve problems with the their projects. At crunch times,with limited resources, they are unwilling to put in any time or effort to assist the team.
That being said i also have worked with amazing PMs that have been there through the entire project. They knew every little detail about their project and were always available to answer questions or help resolve problems.
I would say that a majority of the PMs i have encountered deserve little respect and are lazy and ignorant. The few PMs that have earned my respect have not received the recognition that they deserved.
Oh for fucks sake, does this topic really matter? None of us are experts, irrespective of what talents we think we have. We’ re all doing the best we can, but ultimately we all do better when working together. Job titles are so last century.
Yes I would tolerate the PMs’ presence if they stayed away from calibrating employees and giving them a performance rating. Why don’t they stay away, and we would tolerate their presence like we tolerate the presence of non engineering staff like janitors, coffee machine cleaners, etc. Oh wait, but they actually do useful and arguably indispensable things, but they don’t take part in calibrating engineers…
Just like a sports team does not has a head coach?
Like it or not projects need PM, without anyone managing a project there will be nobody to ensure that people are working efficiently enough so that the project is on track to prevent delays. That is the nature of commercial programming I am afraid. A good PM would also mentor and coach his colleagues with some technical awareness. They often also deal with client requests and since the client is setting the scope this is essential to the management part of the project – something that the dev team does not do!
To some degree project management is required in any project, that’s true. However in IT there are also a lot of small projects (many with a single person working) that don’t require much project management and using a dedicated project manager would be just a waste of money with virtually no benefit.
For example I have seen projects in which a company for example wants some new features for an existing application and for that it contracts another company that does the work using a single employee. That employee is typically a technical consultant who talks to the users identifies the requirements determines what needs to be done estimates the effort, does the planning and finally the actual work. This employee also reports to the customer the status of the project.
In this scenario the company that does the work is typically payed by hour and the time needed to complete the work is being estimates by the consultant and approved by the customer.
While this approach may not be applicable for larger projects it makes perfect sense for smaller projects and demonstrates that a professional project manager is not always needed.
A couple of months ago I met a person working for a very large corporation that was about to start such a one man show project for a customer. I specifically asked her if there is going to be any project manager involved and she say no as she will do by herself everything that is needed to deliver the project.
The whole flaw in your argument is that there has to be somebody has to manage the ‘technical consultant’.
If there is no PM managing them, then it will be the client. Do you think that the client has the time to manage their day to day activities. Has the time to (if following agile) to produce release burn up reports to work out if their velocity is in line with when the project should be released. The other advantage of having the middle man, is that the reporting will not be fudged but accurate.
Also it is all good with saying that “This employee also reports to the customer the status of the project.”, what happens if this employee (sub contractor) disappears mid way through the project, who is going to chase them up – the client?
Finally, good PMs do not let the developer do all of the requirement gathering, they do it with them. They have several meetings discussing on a high level what the client wants. They then write a functional specifications document, where every requirement is clearly broken down into user stories, with acceptance criteria’s which is then approved by the developer and the client. This saves the developer a tonne of time, since all they can then focus on what they do best, and is getting on with coding the product. If there are any problems during the build of the product i.e. client wants changes, the developer doesn’t have to worry about talking to the client, since the Project manager does that for them. Hence, the project manager ironically needs to know the project inside out to do this!
I recently managed a single sub contractor in this set up.
@SS
Well the technical consultant can manage himself very well as long as the non-technical aspects of the project don’t take too much of his time so he will not have enough time to do the actual work. I have worked as a technical consultant and it was my task to gather the requirements from the customer figure out what needs to be done and then do it. I didn’t need someone such as a project manager to tell me what the business users had already told me.
Now if we are talking about a project that implements a new software solution then yes you need some people to manage the operational aspects of the project, gather requirements discuss with the business users about what needs to be done, report, do administrative tasks, etc. Technical people usually can’t manage these things because they are too many in these kind of projects and they wouldn’t have time to focus on the actual work if they were doing those things. In addition, many technical people may not have the right skills for this.
However, after the project that had implemented the solution had finished there will be usually someone to support the software and fix the defects that inevitably will be discovered. While using the software the users will usually also discover that they would like additional functionality or something changes in their business processes and additional features are required. Some companies include in their support and maintenance contracts the ability of the customer to add new change requests to implement new features. There is usually a system where the users can log both defects and enhancement and the developers or the technical consultants work on both, defects having higher priority. In this way software development can continue outside the scope of a project and no project manager is needed.
The new features may be implemented also as part of small projects, which are basically a set of change requests for which an IT professional or a very small team commits of doing usually for a fixed budget. In these cases, there are very few project management issues and there is no need for a project manager to work full time. If a project manager is used for these kind of projects, then he/she will have to work on several such projects simultaneously in order to fill his/her time. Small companies may not even have enough projects to keep the project manager busy full time so they don’t hire one. Although this doesn’t happen to often even larger companies may choose not to assign project managers for their smaller projects in order to reduce costs.
Adrian, if the project is very simple, say for example the project is to deliver a 5 page static WordPress web site, then you are right, the client can get away with not having a Project Manager and just work directly with the ‘technical consultant’.
However, if it is a serious product that the organisation is building, or there are a series of projects that need to be delivered, then the organisation defiantly needs a trained Product or Project Manager, especially if there is a cross functional team assembled to achieve this. Developers, QA testers etc etc Somebody has to manage them.
Likewise, there is also a lot more to getting work delivered then using a ticketing system. Somebody has to manage the ticketing system for started, by first talking to the client and finding out what is high priority and what isn’t. Letting the client open tickets is a really stupid way of doing things, and the Support and maintenance team should NOT be accepting tickets that are full blown features without a face to face conversation. Since, very often full blown features is often a pre-requisient to a new version of the product, where a new version product road map needs to be documented by writing really well thought out user stories with acceptance criteria. If you do not do this, you risk the developers implementing useless functionalities or even worse creating functionality that is not how the client wanted it.
Also expecting the developers to do the admin side is a poor a way of managing any project. A good project manager will not let them do any of this, for the sole reason that their strength is coding. Many developers that I have worked with are happier with this set up, since it means that they have less work to do and can focus on their ‘sprints’ (I am an agile project manager)
Finally, having amazing technical skills does not make you a good project manager. When I was a developer, I worked under ‘tech leads’ who were absolutely useless at management. For example, the one that comes into my mind right now was absolutely useless at resource management (how to build a team, motivate people etc). His idea of management was micromanaging and treating his colleagues as a ‘pair of hands’ using ironically a ticketing system that you’ve mentioned. It didn’t work because when he opened tickets half of the tickets were very poorly documented leading to disputes regarding if the work is done or not. Also, his reporting absolutely sucked, he did not use anything to measure productivity and just blamed the developers at the first sign of trouble.
When you practice project management,you quickly learn that it is less about technical ability, but more about understanding people, learning how to get the best out of them, and putting management processes in the operational side of the business (reporting, structuring your resources properly) in place to get the team to collaboratively work together to help the PM deliver a high quality product.
As a former developer/project manager that has worked in many organisations – from start up’s to agencies, aside from the above, I have seen how poor project/product management has caused excessive delays, and ends up costing the company more in the long run since it affects their ability to execute in a timely manner. Very often this in turn causes cashflow problems, or allows the competition to catch up. Having a trained project manager on board to keep things streamlined reduces the risk of this happening.
@SS
The idea is than in a project the role of the project manager is optional. It is possible to deliver without having a project manager and many IT projects (mostly smaller ones) are delivered in this way. It is not the team who helps the project manager deliver but it is the other way around. Project managers are brought mainly to improve the performance of the activities that involve change. The benefits that project management brings however depend on the nature of the change activity and in some activities elaborate project management methodology and professional project managers simply make no sense as they will not bring real benefits to the business.
I will give a clear example. I had recently worked for about 2 years supporting the GIS applications used by a large utilities company. By supporting I mean I was fully responsible for all the aspects of the applications including developing new features. I was working at the customer site collocated with the team that was using the applications so for any issue they had with the applications they came straight to my desk and talk about them.
If they wanted new features they simply came to me and told me what they had wanted, I was analyzing the requirements figure out what needs to be done and then started to do the actual work. I was working in a development environment where the users had access so they were testing during development and they were able to give me further instructions about the new features they wanted. The requirements were recorded as request for change records into a system and it was the senior user who decided which requirements had higher priority.
While we were not using any agile methodology in my opinion this was real agile as the users were directly driving the development and there was absolutely no doubt that what I was developing was actually what they wanted. In addition, there was no pressure to finish in a set time or budget (the company was paying a fix sum for support) and the scope creep was no issue as they were able to change their mind about a certain enhancement while I was working on it with absolutely no impact on the budget. I am not sure if the contract had a minimum number of enhancements included but the users were very happy with the progress and with the ability to basically do whatever they wanted to the applications.
Once the work was done for a requirement it entered a Change Advisory Board process and once approved I was allowed to release it into the production environment. The CAB was managing changes for the whole IT department not only for my applications.
The real limitation of this setup was the fact that the amount of requirements I was able to complete was limited by the time I had to work on them as the defects and other issues had higher priority. If they wanted the requirements to be done faster their manager had to sponsor a project which meant, he had to allocated extra money from his budget for this. The requirements had to be estimated and according to the estimation the required budget was defined. The functional manager decided how much money he wanted to spend and as such some requirements had to remain out of scope and they were done as part of the Business as Usual process.
When a project was started usually another consultant was assigned so that the requirements can be completed faster. Also project managers were assigned for each project but they were dealing with reporting and other administrative tasks and they were not involved at all in the execution of the project as the consultants were doing all the work including directly interacting with the customers. Each project manager was “managing” several projects simultaneously as there was not much work for them to do on each project.
We are going around in circles, but to cut a long story short if you are the only person working on a client project it is NOT management. When I am managing, I am managing a cross functional team consisting of UI/UX, developers, QA testers to work together throughout the whole software development lifecycle to help me deliver a project.
Also what you describe when it comes to agile is agile not properly executed, which is all about releasing the product in increments. If you are finding that there is a lot of change requests with the client it basically means that you have not done a great job with speccing what they wanted originally to begin with.
Finally your project management style does not even scale, yes if you are one guy working on a client project it’s easy. But what if you have a team of developers working on it? 10 + are you honestly going to tell me that you will be able to focus on all of the technical work and manage their productivity at the same time? – basically be an account manager, developer, scrum master, product manager – you will be so overwhelmed that it will be hard to focus on coding.
@SS
Please don’t get me wrong I am not trying to say that project management or other non-technical activities auxiliary to software development are useless. All I am saying is that in many circumstances some of these auxiliary activities are an unnecessary overhead that brings no benefit but slows down development.
When you implement a new solution and have a lot of stakeholders and a cross functional team then yes you definitely need someone to see the big picture and to manage the communication between all the stakeholders. I am not contesting the benefits of project management in general I am just saying that there are many commercial software development activities that simply don’t need project managers.
When I worked on supporting those GIS applications at some point the users had needed a new type of fiber terminal in their network to model a new situation that was not present from the beginning. For this requirement the data model had to be changed to accommodate a new table and new fields and also the code had to be changed to support new functionality for the new objects.
If this had been done through a project it would have taken much more time to complete because it would have involved more people such as a project manager, business analyst, quality assurance engineer and maybe a solution architect. The project manager had to organize meetings for all these people to meet and discuss about the new features and decide what needs to be done but I already knew what needs to be done and I needed no further help from someone else. I had just started working in the development environment and when done the users had tested and approved the change. I then got the approval from the Change Advisory Board and finally I put the changes into the production environment. Very fast and efficient with no unnecessary overhead.
I repeat I am not saying that project management is useless and I do understand that in more complex projects there is simply impossible for technical leads or other technical people to manage the operational aspects of the project. Nonetheless even when a project manager is actually needed and he brings real benefits to the project the team does not help him deliver but instead he helps the team to maximize its potential. At least this is how I see things.
Finally, users requesting new features after the project had finished does not mean that the project had failed to capture all the requirements. Usually users want more features than the budget allocated by the functional manager allows and the missing features are normally implemented in future projects or as part of the support operations. But more importantly, as I have already said, the business processes change over time and new features need to be added to the application in order to accommodate these changes.
@Adrian83
I am glad that we are on the same page.
To summarise
1) If it is a project that requires one person, and it is a short one off project, then it is probably not complex enough to warrant a PM. Many software companies and agencies, do not hire PMs for these type of roles.
2) If the project involves getting a cross functional team together to help deliver a couples project/product than a PM is vital in order to keep the communication lines open, and delegate work correctly..
To give you an example of my day to day duties, I am currently product managing a product of a team of 4 people. Before I came on board, the product was poorly written, working with the team my task was to help them launch a newer version of the product. Previously the challenges the company had was that they were managing it how they always had done so before, they would:
– give the dev team a shopping list worth of work which is unrealistic in the time frame expected
– not doing proper QA based on properly written specs leading to a lot of bugs or worse still functionality that the client did not want built.
– asking for a 1000 change requests when the developers are already half way though working through a task. Causing them to lose focus with completing tasks from distracted, leading to poorer quality work being produced.
– Delegating work to staff that were too junior for it
Once I came on board, I:
– Put processes in place to do efficient QA by writing descriptive user acceptance criterias.
– Changed the way the company worked so that they released increments of the product every fortnight
– If the client requested changes it was prioritised based on the upcoming sprints.
– Managing stakeholder expectations by showing them reporting of the team’s velocity relative to the amount of work left. Changing the way they think about the process of software development.
– Doing all the admin side – requirement gathering etc, so that the team doesn’t.
The end result:
– high quality product
– happier developers
– happy stakeholder
– more focused team. Since they can get on with what they are good at.
Where am I going with this, the people complaining on this blog post have no idea about what goes into project management, arguably it is much more complex then the tech side since it is all about planning and execution. Real people can also be tricky to manage at times since they have to always be motivated and have a sense of purpose in order to get the best out of them.
So glad I can get rid of dead weight. No compassion at all for kids who think they’ve ‘arrived’ just because they have a four year engineering degree. Some learn to see the world correctly. Most do not. 100% of the stubborn debators do not last. Their ‘growth’ won’t come at the expence of ‘the baby’. Feed the baby. Love the baby. Change its diapers. Or, get off.
Understood Lee. Everyone does the best he can in a team. But that best could be put to waste and the team could become lame when nobody is coordinating are reporting progress. And remember, the bosses only want the bottomline which the reports that the PMs give can serve.
I was a developer, now I am a PM and I can tell you that PMs are extremely important when it comes to delivering a project on time in budget. I have worked with tech leads who are extremely technical but had no clue how to motivate the team to get work delivered. My ex line manager was like this.
Sure – they are not expected to code, and often do not. But outside of that, they are the first point of call for clients; they also have to make sure the work is being delegated properly; constantly motivate the team; deal with any impediments. To top it off , PMs are often judged by how efficiently they are able to deliver the projects on time and within budget.
It sounds like you have worked under bad PMs.
I agree with Jane a 110%. The good PM’s don’t get respect. And the ones’ that get high visibility and praises are the one’s who actually forged it by taking credit of others.
I’ve worked with a bunch of bad ones and few good ones. The good ones prioritize requests, make educated judgement calls on which tasks a developer should devote her resources on, can answer questions about technical requirements.
That said, most of the PMs I’ve worked with are abysmally incompetent serving as nothing more than glorified secretaries. For the recent project the one checking QA status, prioritizing bugs, confirming business requirements, is ME, THE DEVELOPER. 1. The PM couldn’t answer ANY of QA’s questions whether this or that bug is launch critical or not. 2. The PM failed to assign the most important tasks to me, 3. nor did they rank various QA feedback in ANY order of importance. I don’t know what their role is, they’re out of the office half the time. All I see them do is scheduling meetings on the calendar and taking attendance at stand-ups and ask “Is it done yet?” If it’s not, they wouldn’t know what to do. If it is, then they’ve “done their job”, which is nothing basically.
Everything you said is correct. Have you forgotten to mention that these scum of the scums however take part in calibrating their employees and give them a performance rating, and make their life hell?
Doing the performance review of an employee (who is not a line manager) requires the reviewer to be from the same line of work as the employee. That’s because the technical aspects of the employee’s work have to be taken into account.
If the project manager is a good technical expert being able to do the work of the team members then he/she may be allowed to evaluate their performance or at least send performance feedback to the team member’s line managers.
Project managers without technical background or who are not very competent technical experts are typically not allowed to review the performance of the project team members as they don’t have the competence to evaluate the technical skills.
Companies that allow non-technical project managers to evaluate the technical abilities of the employees working on projects may end up loosing their best human resource as the work of this resources may not be well rewarded. In addition the workers may feel themselves humiliated when someone that is not able to do their work evaluates how well the work was performed.
First and foremost, you are right a non technical PM should not evaluate a technical person’s work. Although as a PM, I do think that it is important that the PM should have some technical awareness, but at the same time I am aware that there are many companies who do not hire technical PMs.
Secondly, the problem with this whole debate is that you have a lot of PMs that do not do things properly in terms of measuring productivity. If for example you do follow the right methodology it is easy to measure progress of the team.
For example Agile, when work is delegated it is done during sprint planning sessions where with the Product Manager and the team agree on what backlog items to complete in that week. The scrum master then takes over (some do both roles) and productivity during sprints is then measured based on velocity using burndown charts etc. Hence, if the dev team agreed to complete x amount of work but never manage to meet their sprint goals and always behind on their sprints, there is obviously something wrong with either the way the sprints are organised (too much work), or the developers are just not good enough. If done properly, you can work this out as a non technical PM, you do not need to be technical.
Now if you have a tech lead, and their strength is coding, do you not think it’s better for them to be involved with the rest of the dev team coding during the sprint as opposed to administrating it? The whole point of the sprint is that the dev team can do what they do best and NOT get interrupted by stakeholders etc…somebody has to do this job.
A lot of the people moaning here, are clearly disgruntled developers who do not understand why project management is important. They have probably also worked with terrible PMs, who just order people around.
From doing this, I have seen that so much more work gets done when you have a clear separation from operations and the hands on technical side of the business, since the developers become much more focused on developing new features etc.
We all agree that non technical PMs should not be allowed to evaluate the performance of technical employees. But Google, which is a much hyped dream company has exactly this abominable setup. Peers also provide reviews but peers’ reviews only get considered for promotions, not for calibrations which is a separate process. For calibration, the manager gives a score even if he is a non-technical idiot.
+1
As a PM, I have dealt with other PM’s that are how you described. Since I come from a pretty technical background and do QA, and learn about what is going on (sometimes suggesting to the dev team how the problem could be solved) it absolutely pains me when I meet a PM who has no clue at all. These are the type of PMs that give the rest of us a bad name. I am no longer hands on, but I do so much reporting that I wouldn’t have the time to be. There is a lot to PM if you run your projects in an agile way.
A complicated task or business objective needs project managers to implement manage and deliver them, someone needs to be accountable for a projects success or failure at the end of the day, projects have critical paths and tasks that requirement such as planning, seeking approvals, time and budget management, risk management contract management and many other crucial business impacting tasks that need to be considered, Without project managers there will be no plan, no time management, budget blowouts, risks which could put the company’s reputation In jepotdy, etc etc the biggest concern for a project manager speaking from experience is “people management” if you cannot built relationships with your project management team all of the above will be a nightmare, I have seen other project managers struggle in this area and it only results in their reputation being tarnished by the team,
Absolutely agree with you R. Every PM must be sharply honed with that art of “people management.” In the company where I works as A Project Engineer, I always deal with people that belong to different discipline: Product Engineer, Process Engineer, Technicians, Production Sups, QAs, Planers, Supply Chain Analysts (SCAs). Each one has their own mandate for the day. And if he is not reporting to you and the Task is not his priority for that day, he won’t update or take the Task loosely. You’ve got to be patient and got tons of provision of it for explaining later to the Boss why the Task is late…and here is the catch: the explanation should not give impression that you are blaming the Task Owner. He takes it as you burning the bridge. This is where I learned to fatten my Emotional Quotient. Even if I hate a member, I have to find a way to like him to the point of treating for a dine or drink or be the first one to greet happy b-day and give gift–just to win his emotion and not to snub my update next time.
It works most of the time…but there are really some people who are borne with obstinate horns!
Ps – I have a technical engineering background with a project management degree and the project managers I see struggle are the ones who have no technical capability, it’s hard to build relationships with project engineers when you can’t speak their “engineer Lingo” same goes for “executive msnagement” you need to speak there lingo to that’s why I went and did an MBA after – sad but true!!
Btw – mind the spelling (it’s 4.30 am)
Obviously, if you think PM’s are not needed your projects are too small. I’m a technical PM but more a Delivery Manager/Solutions Engineer/Developer/BA/etc. I’ve worked in sales, fulfillment, support and development of an online marketing company. We’ve built new platforms, platform integrations, migrations..you name it, we’ve done it.
As a tech PM I handle the managing of development, the architecture, business and tech requirements, documentation, (what API/Daemon pushes what data) and making it sure that what is being developed is functional for all channels. I work my butt off to produce and exceed expectations. Without a PM to manage the project as a whole, who drives marketing/documentation/communications and/or every other aspect beyond the technical side? Someone is going to use what is being developed and it is likely more than just CX but a global CX. Every front end also has a back end.
I will tell you this, there are more terrible PM’s than good PM’s by a landslide. However, if you get a good one, you will know it. I don’t doubt that if you handle projects to create a simple db with a UI that’s used internally, that you do not need a PM. However, if you are developing a new control panel with integration of several other platforms, a front end user experience, a back end user experience and training several hundred sales/support/fulfillment reps on the new integrated platform, you’d better have a dang good PM running the show or that project will be disastrous.
All engineers are mad because the PM is above them. LOL sad but true, they hate that they cannot be leaders nor make good judgement when things get tough. PM’s are strong and good leaders so all the cry baby engineers grow up and keep working!
What on earth are you talking about you’re just a glorified secretary. What judgment ? You still have to talk to upper management and explained the risks so that you can wash your hands if it fails, remember re-mediation tasks tasks ? Can a project manager survive without an engineer or architect ? I dont think so.. But can an architect or engineer survive without a project manager? Guess how startups are made.
Engineers can’t be leaders? You’ve got to be kidding. Managers in engineering companies/engineering departments are promoted from among engineers and not from among project managers. In fact project managers in the overwhelming majority of cases are not even real managers as nobody reports to them not even the project team members.
Also the overwhelming majority of decisions that engineers do care about are technical in nature. If the project manager is not also a very experienced engineer then he will not lead the engineers as they expect technical direction from their leader something that he/she will not be able to provide.
Project managers have their very well established place in technical projects however they don’t get involved in engineering or in leading the engineers.
Engineers who are Managers are called ‘Tech leads’.
Not all tech leads are good at project managers, which requires a different set of skills; good communication skills with stakeholders and other parties; reporting (gaant, burndown charts, maintaining the product road map etc) and budgeting.
A good tech lead should be focusing purely on the technical aspect of things, as opposed to being involved in operations which is what a PM does.
Engineers who are managers are called: engineering managers, directors of engineering, vice-presidents of engineering and chief technology officers. Well they don’t do much engineering but in order to get on these jobs in almost all cases you must have an engineering background. This positions are known also as functional managers (with the exception of the CTO who is an executive manager).
Technical leads are not managers they are technical experts such as engineers who are responsible for leading a group of people from their own line of work during a work activity such as a project. The role of the technical lead is usually not permanent an engineer may function as a technical lead on a project and as an “ordinary” engineer on another.
Project managers are not managers either, but instead they are professionals in the field of project management responsible for managing the operational aspects of projects. It is very true that not all technical leads are good project managers but in most companies technical leads are not expected to do project management so this is not a problem. :)
In many if not in most companies engineers and project managers are at the same level (the bottom of the chart) and they have different career path options. Engineers can become functional team leads, engineering managers, directors of engineering and at the highest level possible chief technology officers.
Project managers can become program managers and then they can end up leading the project/program/portfolio structures from the organization in which they work.
There you go, that proves my point that people on here complaining about PM’s do not know what they exactly do, and therefore do not see the value of having them!
They are not glorified secretaries.
In a nutshell, they help run the operational side of the business whilst the tech lead/manager needs to keep up to date with tech trends and all things technical and work with the PM. The PM does not have to be technical. Though it helps.
Skills such as:
– Resource management
– Stakeholder management, which for the record is very hard if dealing with impatient stakeholders.
– Reporting progress using reports
– Budgeting
– Awareness of different project management methodologies and WHEN to use them
– Planning, forecasting
– Delivering projects on time and within budget
– Dealing with conflicts/impediments as they occur
These are all non technical skills a PM must have to ensure that everything on operations goes smoothly. A good PM will take the pain from the development team on the operational side so that they can focus on doing what they do best, writing code and implementing functional specs.
For the guy who responded to me telling me that start ups need developers, but don’t need a PM. The last start up that I had worked in that took this approach ended up having endless delays from poor requirement gathering and a lack of overall planning on how work should be distributed with the Dev team. The person managing the start up was a tech lead assuming the role as PM.
SS, them PMs may bring a small value as you say, as does the janitor. Why don’t these PMs be under engineers and get a fraction of their salary, coz that’s what is the right thing to happen. Which psycho invented them to be above engineers and get paid more than them?
Underrated, you are missing the point.
They are two completely different jobs, one job (engineers) is about building things, the other is about ensuring things that are built by engineers is done in a timely manner.
I was a former developer before being a PM, when I was a developer in some ways my life was easier. Daily routine would consist of getting a list of functional specifications, and just implementing them. I had less responsibility.
As a PM, I have a huge amount of responsibility, I have to make sure that everyone in the cross functional teams works together in a cohesive manner to help me deliver a project on time. That is why PM gets paid a lot, the job is stressful from carrying more responsibility and with that comes more accountability when things go wrong. I.e. Delays, project going over budget etc
It depends on the company but usually large companies use something that is being know as the weak matrix organization. This means that the project managers are not above engineers but instead they are at the same level on the company chart as employees sitting at the bottom of the hierarchy with no one reporting to them.
Project managers usually sit above engineers in the cases where becoming a project manager is part of the engineer’s career path. This means that the project manager in this cases is an engineer promoted to a higher position. This is known as the strong matrix organization.
If the project manager is not an engineer then he usually does not sit above engineers and the engineers in this case report to some kind of engineering manager which is an engineer promoted to management.
Regarding the pay it depends on the company. Usually companies value more the employees that are in direct contact with the customer and that’s why project managers that manage projects delivered to customers usually make more money than the average engineer.
On the other hand top technical resources in many companies are paid much more than the average project manager as they are more important. Loosing a good project managers is usually less important then loosing your top technical resource. Loosing an average engineer is also less important that loosing a good project manager.
Lastly projects are not born equal as some of them require far more project management expertise than others. This can lead to projects where there is not much work for the project manager to do. In this kind of projects the PM is essentially an over paid administrative assistant and if he/she is paid more than the engineers then the engineer’s frustration is fully justified.
Once again this argument is flawed in the sense that it is comparing apples and oranges.
In many organisations PMs and Engineers work together – Adrian, you are right, PMs have to deal with the customer, may it be stakeholders or externally which makes it a very stressful job. Anyone who has done account management would understand this. Many developers bitching on here thinking that being client facing is not as ‘hard’ as coding, but I would love for them to experience a situation where there are massive delays with the customer threatening to stop doing business with the company over it and see how they calm the customer down especially when the customer is not technically minded (often the case)
To add to the complexity, if it turns out that the company ends up losing a client (affecting cash flow), the Dev team does not get blamed. The PMs neck is on the chopping board. The pressure from knowing that alone adds to the stress. Adrian when you think about it this way, it is unfair that you compare PMs to administrators, many admins have far less responsibility than a PM where their actions do not affect other departments in the same way – sales, HR, technical since they are not delivering projects using resources from these departments but passing information around. That is an extremely important distinction between the two roles.
Both engineers and PMs are paid well for different reasons. Reasons such as above is one example why a PM is paid well. Other stresses in the job include leadership skills, motivating, keeping morale in the team high so that projects are delivered smoothly on time and within budget. Easier said than done, when working with difficult colleagues.
Now to give an example of the above, recently I was in a situation when trying to deliver a project but the developer was either not doing the work, or very slowly. Now I can’t just complain about this the CEO or stakeholders, to save my neck, I have to first have substantial proof that he indeed is not doing the work from adequate reporting, once that is done I then had to find a replacement.
Again, sounds easy? How about putting yourself in a situation when your team are not hitting deadlines for the reason above. Resolving resource bottlenecks and making decisive decisions is part of the job and requires leadership and strong management skills.
These are just two types of scienario a PM has to deal with, there are many more.
The problem with technical people is that they only care about technical aspects of an organisation and are out of touch with the companies strategy in the next quarter which is defined in operations.
@SS
I didn’t say that project managers in general are administrative assistants. I only said that this depends on the project. Whether you accept this or not there are a lot of projects in IT (usually less complex ones) where there is simply no need for professional project managers. There are projects where there is a single technical consultant/developer who talks directly to the customer figures out what he needs to do and does it by himself/herself.
In addition some companies add enhancements to their software as part of a support contract which means that for a fixed periodic fee the users can log requests for both bug fixing as well as for enhancing the application. In this scenario we don’t even have a project.
As for evaluating the performance of employees, project managers, unless they are also very competent technical experts themselves shouldn’t and usually are not allowed to do this.
The fact that a developer misses dead lines does not mean that he is a poor professional. The dead line might have been imposed on him by people that have no idea of the work that needs to be done and he may not be willing to take shortcuts and deliver a poor product or a product with a lot of technical debt in it.
The performance of a technical expert can only be truly evaluated by another technical expert. Personally I have never seen cases where the project manager can kick someone out of a project for performance reasons. The best he can do is raise the issue about the performance problem and escalate it to a decision maker such as the project sponsor or the line manager the team member reports to. If the decision maker concludes that there is no performance issue then the PM has to live with this decision. Sometimes even if there is a performance issue the sponsor or the line manager can’t find a better expert for the job so tough luck for the PM.
In the companies for which I have worked the PMs were not solely responsible for the outcome of the projects but instead the line managers were also responsible for their part of the work. Project managers were not even recruiting team members but instead they went to line managers who were responsible for allocating resources to the projects and ensuring that they perform at their best. If a team member was not performing well on a project then his/her line manager would have been held accountable for that and not the project manager.
Adrian, don’t get me wrong, coming from a technical background does help immensely. Very often when I am managing my in house team, and they run into technical problems I help them out where I can when they are stuck. I do think that all PMs should have some technical awareness in order to better understand the project so that they know what they are trying to deliver. However, they don’t need to be an expert, they just need to be competent.
The bulk of my work however is largely focused around my soft skills rather than my technical skills. I spend A LOT of my time planning upcoming sprints on a weekly bases and ensuring the work is delivered – I’m currently leading a team building a start up product using Scrum. To do this properly, I have to work with the product owner and devise as well as maintain a product roadmap which is in line with the needs of the market based on the user stories in the backlog. This is not technical at all, but more in line of PM/business analysis.
I disagree with your opinion that productivity can’t be measured!
Productivity can be measured using cumulative flow diagrams , burn down charts, and allocating reasonable story points to user stories in the sprints. The story points FYI are not set by the PM but done collectively together during sprint planning sessions so that the complexity of the task is discussed and agreed with the technical team before a story point is set.
If done properly you can work out the average velocity of the technical team using burn down charts over period of several sprints. This is then used as a guide for future forecasting on how long it will take to deliver future work and during the sprint help the agile project manager keep the team on track by reviewing the teams velocity at the end of each day on a burn down chart once the sprint has undergone.
If the team works a certain velocity, where the velocity suddenly drops then there is something wrong. I.e if they stop meeting their sprint goals, or start to continues let fall behind on the burn downs.
A good PM needs to also know how to switch methodologies, for some projects I don’t do scrum I do kanban. When I do kanban, I track someone’s work rate based on their cycle time.
So you see, what I have described above is low level project management.
Knowledge of when to apply different PM frameworks to get a project delivered in the most efficient at possible; using various reporting tools to measure productivity and KNOW HOW to do it properly adds another dimension to it.
@SS
Software development unlike construction, manufacturing, digging trenches, etc. is a creative activity where you can never accurately estimate the effort needed to complete a task. Because of this it is virtually impossible to accurately measure productivity in this field especially by using statistic data that tells you how fast do developers complete their tasks.
If you are digging trenches and know in a working day, the length of the trench the workers can dig then it is very easy to estimate how much time the whole trench will take to complete. If you want it done faster, you can add more workers in shifts and you can accurately estimate the new end date.
The trench estimation however does not work in software development. If you look through statistics and find out in average the number of tasks/user stories a team or a developer completes in a certain period of time it is foolish to use this information in order to calculate the number of tasks the developer or the team will complete in a future period of time.
Even if the developers work as hard as they did before and have no impediments it is perfectly normal for their “rate” to variate, sometimes even dramatically. I can think of a lot of reasons for that: the complexity of the tasks is much higher, the complexity does not change but the developers have to use different APIs or algorithms that they haven’t used before, the developers have to pay the technical debt that they had either produced in previous projects/ sprints/ project phases or the technical debt was already there produces by someone else. Not to mention the lack of inspiration that developers can have some times. If you are working on a more complex task the idea on how to do it can come to you straight away or in a couple days or maybe never.
While my work now involves a lot of coding I am not a pure developer as I also interact directly with users on gathering requirements and defining solutions for their problems. At my beginning of my career I worked as a pure developer and one of my first assignments involved outsourced bug fixing and enhancements. My company was paid by the number of bugs fixed. You can imagine by yourself what happened, we worked as hard to fix as much bugs as possible without carrying too much on the quality or on preventing technical debt. Many of our bugs returned to us as they failed technical review or testing and even those that passed were a sloppy job as all we cared about was speed.
If the developers line managers look at this kind of statistics for performance review and pay raises purposes, then things can get really messy as less competent developers may end up with better pay because they worked on easier tasks that they were able to complete faster.
Adrian, the whole point of agile is to not 100 percent work out how long a task will take, but to plan your sprints based on the complexity of tasks relative to others.
If this is done well, you’ll eventually see a pattern over several sprints with regards to how many story points the Dev team can complete on average. You can find this information by comparing past velocity on burn down charts.
My Dev team for example completes 9.5 points on average. Hence, if I plan the sprints with less points, I often have found that they end up finishing well ahead of schedule. Similarly, if sprints are planned with more points then they risk not finishing all of the work in the week. It’s the PM job to work out the happy medium.
Finally, and the point that you are missing. The agile PM does not decide the story points of tasks without first discussing this with the Dev team. The whole point of the discussion is so that the team as accurately as possible measure how ‘complex’ a task is (note: this not measured in time) relative to another.
A skilled PM, knows how to consistently do this. They can also use this as a guide to measure productivity, if for weeks on end my team are completing 9.5 points worth of work, than all of a sudden can only complete 3 points worth, then it’s reasonable to believe that there is something wrong – either with the developer not working hard enough or if the tasks are not properly estimated.
In addition, you can use a cumulative flow diagram to see the overall progress of one developer.
I can tell from reading your post, that you are not a PM at all but a pure technical person that has probably worked in non agile environments.
@Adrian, to add.
The fundamental problem with your whole approach, which is basically leaving the developers to self manage is that you leave yourself vulnerable to a developer setting unrealistic timeframes, in turn producing very little.
In addition, when dealing with stakeholders you need to be able to give them timeframes as accurately as possible. You cannot go in and say:
‘Hmmm I don’t know, the problem with software development is because it is hard to estimate mmmm…how long is a piece of string?’
Agile is not meant to be 100 percent accurate, but it is a lot better than the way you are doing things, which is pure guesswork and does not scale when trying to work out the work rate of whole Dev teams.
Commercial development does not work this way. Like it or not, developers need to deliver work based on timeframes.
@SS
In all activities, whether or not we talking about software development, the subject matter experts that have experience in doing the work are the best people to do the estimation for the time needed to complete the work.
I don’t want to offend you in any way ( I don’t even know you) but saying that the software developers are not the best people to estimate the time needed to complete software development tasks is simply absurd. It is statements like this that make some project managers get no respect from technical people.
Is like you are saying to a professional in a certain field that he is too stupid to estimate his own work and you, even if you are not as good as the expert or are a total non-expert, can better estimate then he can. And the bottom line would be to hold accountable the expert on the estimation that you as a non-expert or as a less competent expert did.
On all the projects on which I have worked the effort needed to complete certain tasks was either estimated by me or by a better technical expert that was on the team (technical lead, solution architect).
If the estimations are too long then the project manager will try to find solutions by engaging other people or trying to get new members on board to help. It is the technical people and not the project managers the ones that will find the solution, the project manager will just guide and engage the experts and other stakeholders on finding the solution. If everything fails then is it the obligation of the project manager to raise the issue to the sponsor warning that the project has a high probability of failure because of unrealistic expectations.
On the projects on which I have worked the project manager (when one actually existed) was not responsible for taking decisions regarding the project but instead he/she had to find out what decisions have to be taken and then ask the right stakeholder to take them. When it was time for estimations the PM asked the technical experts to produce them.
In my opinion, unless we are talking about less complex projects, the role of the project manager is very important but his value doesn’t come from getting the status, writing reports or from gathering statistical data but instead from managing the communication between stakeholders and translating the status of the project to the customer in such a way that the customer will be happy and be convinced that he will receive a good product or service. In my opinion only for these activities the PMs deserves a high pay.
The best project manager is the one that makes all the stakeholder happy. :) A project manager that doesn’t do much stakeholder management does not bring much value and he/she is basically a glorified secretary.
@Adrian
I never said that software developers should not estimate their work, more to the point during ‘Scrum planning sessions’, I encourage this and it leads to a discussion. I just think that you should not blindly accept developer estimates when you are managing them.
As a Agile PM/Scrum master, I often challenge the development team (I come from a technical background so I can do this) in case they give an estimate that is too conservative. I have seen this happen many times, where the developer judges the complexity of a task to be 3 points worth, but after the team questions why and discuss the problem throughly, the effort can be less.
I totally agree that stakeholder management is important, it is something I do daily in my role when I report to the product owner. Often this is very challenging if the stakeholder is non technical and when things are not going well.
At the beginning of my career I worked as a developer on a Scrum team responsible for the development of a software product. This was not part of a project, we were not directly delivering anything to customers and as such there was no project manager on the team ( there was no need for one).
This was my only interaction with the Agile world so I am not an expert on this. However I have learned that self managed teams is one of the core values of Scrum Agile. This means that the Scrum Master/PM is just a facilitator that is not allowed to take decisions but instead he/she must help the team take decisions. This means that the Scrum Master/PM can’t theoretical change the estimations made by the team.
The reality however is that even in non-Agile projects the PM in most cases still acts as a facilitator who is not authorized to estimate the effort needed to complete tasks. Many if not most of the software PMs (either Agile or not) don’t come from a developer background and as such they lack any competence on this matter.
Of course this doesn’t mean that the PM has to blindly accept any estimation made by the developers but he can’t reduce the estimations either. He must ask the team to reconsider the estimations (if they are too long) and engage the team members to find solutions on completing the work in less time. This however will usually result in technical debt or in a large number of bugs as the team will not have the time to write quality code. If the team (technical leads especially) remains firm on its estimations then the PM has no other option then raising the issue to a higher level.
Now regarding managing developers it is important to understand the difference between managing the tasks of a group of people that are involved in an activity and managing people.
Managing people involves things such as:
– hiring an firing employees,
– managing the work assignments of employees (for example on which projects they should work),
– providing technical leadership in guidance to employees,
– taking high level technical decisions,
– evaluating the professional performance of employees and taking actions to improve it,
– managing the employees rewards system (pay raises, bonuses, other benefits)
– sanctioning the employees for wrong doings.
Managing people, as a general rule, is not the responsibility of the project manager but that of the functional manager and technical leads. In smaller companies however the same persons my play both roles.
Indeed, that is how Scrum works.
I do not decide the estimates for the team, they do but I do during sprint planning session question why the estimate is that and if they should reconsider. When I ask them to reconsider it is based on experience – if the developer says ‘the task is 3 points worth’ but then in previous sprints they had done something similar and saw that the complexity is less than what they are estimating now. I know that they are misleading me in order to be less productive.
There is a lot of reporting tools in agile where even if you are not technical can get an idea of the teams overall performance. The whole point of the scrum master is relaying progress back to the stakeholder and optimising the sprints so the time the developers have is used efficiently.
@adrian, Google ‘poker planning sessions’ to get an understanding on how I do my estimations.
Actually, the following is a good article that covers this activity:
https://www.mountaingoatsoftware.com/agile/planning-poker
There is a lot of discussion with the scrum team in the planning, which is extremely important.
Some PM definitely got plenty of time to reply every comment and fight back to prove his/her little use. Keep up the spirit! lol
Maybe because I am getting email notifications on my smartphone…moron.
Holy cow this thread has been running for an epic long time, but yes think of a project manager as a glorified secretary. They are necessary to report to the higher ups on the status of the project. however technical leads and architects are way more important than project managers don’t think that the project managers are all that believe me a project manager is much easier to replace as every non-technical IT personnel that I’ve bumped into wants to be one . You look technical.. But are you?
@kp you are comparing apples with oranges. Technical people do technical work, a PMs responsibility (well mine) is to ensure the operational side of the business is running smoothly. This might sound easy, but it isn’t….finding the resources and managing them so that they help you deliver work smoothly can at times be extremely tricky. For example, last week I was in a situation where a sub contractor I was working with was threatening to stop working on a project I was delivering because he felt that he wasn’t paid enough. I spent the whole morning sorting this out and it was extremely stressful since I need him to complete his work so that we can deliver it to the client without going out of budget.
Meanwhile the technical team, are sheltered from this. Whilst I am sorting that out , they are coding etc.
So no comparing PMs to glorified secretaries is extremely disrespectful. We have huge responsibility and accountability, we have to make sure projects are delivered in time and on budget. If we do not then the company can fold, since customers will not be willing to pay, or sub contractors such as the above cause the project budget to go out of whack affecting the companies revenue stream.
Yes I agree that comparing PMs with glorified secretaries is disrespectful, even in small projects where PMs are actually performing a work similar to secretaries. However I find it equally disrespectful for PMs to claim that they deliver the project and the team members only help.
Saying that the team members help the PM deliver implies the fact that the team members play a minor role in the project. In reality however if you drop the PM you can still deliver (and many small companies do deliver projects without PMs) but if you drop the team members then you have no project.
Since the project manager is an optional resource on a project team it is him/her the one that helps the team deliver and not the other way around. Any member of the project team can perform the work of the PM but in complex projects it is not a good idea to have a team members doing this work and it is much better to employ a professional project manager.
I also find it disrespectful when PMs claim that they ensure that the project is being delivered on time and budget when in reality equally important if not more important is the effort made by the team.
At the end of the day, yes, a PM role is optional, but then that goes with many roles that are not technical. I have worked in start ups where they carry a ‘do it yourself’ approach for sales, and marketing. Only because it ‘looks easy’ does not mean it is.
Before I took on my current role as a PM, I worked in one company that is a start up, where I was a web developer, the organisation took your approach and left all managerial responsibility to the tech lead. Guess what happened? In that instance, the project quickly spiralled out of control in terms of budget and delays. Despite the tech lead being technically able, he was very bad at putting *non technical* processes in place to make things more efficient by reducing costs and ensuring things were delivered smoothly. Similarly, when any impediments arose with his colleagues, instead of diplomatically resolving the situation, he created a culture of blame.
Project managers are hired for a reason, they are not there to provide technical support, they are to ensure that things are extremely organised where impediments are dealt with quickly in the smoothest way possible. A lot of this is on the operational side of the business and requires strong organisational plus interpersonal skills – they also need to have commercial awareness of how the business operates and what it is trying to objectively achieve. A secretary doesn’t, and is not part of the bigger picture which is why it is an unfair comparison.
It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.
Frankly, it is the arrogance that is displayed in this thread that is really pissing me off. Developers on here are clearly frowning on PMs, yet don’t realise how important their role is ensuring that everyone is motivated and in turn productive which in turn leads to a project being delivered in a timely manner tying into the commercial objectives of the business. That is the reason why many digital agencies hire Digital project managers, along with larger companies.
@SS
“It is good for the PM to have technical awareness, and it helps me a lot, but at the same time, I do not need to know it at a very low level, just enough so that the developer doesn’t bullshit me and even if I didn’t have any technical knowledge with the right reporting I could still work out if the developer is bullshitting me i.e. if the developer constantly commits to delivering work, but fails time and time again.”
The above is probably the proof why some PMs don’t get any respect from technical experts. You are basically saying then a person with limited or no technical abilities is able to tell when a technical expert is right or wrong on issue related to his/her domain. Don’t you think this is absurd? I mean how can a reporting tool determine the technical difficulties faced by developers in their work?
Also software development is not digging trenches so you can’t accurately estimate the effort needed to complete a tasks. Estimates in software development have always been a problem and continue to be one as it is not possible to get accurate estimations no matter how good your so called methodology is. That’s because software development is a creative activity and trying to finish something faster will results in a large number of bugs and in technical debt which means extra work.
But even if the developers do give bullshit to PMs and to other non-technical employees, what can they do about it? Maybe ask for a 2nd opinion from another technical expert but if the 2nd opinion is the same then the non-technical people can’t do anything about it.
From my experience however I have learned that PMs are not held accountable for the fact that the developers are not able to finish the project in time since they have no control over this matter.
@adrian83 simple – the developers are part of the decision making process. During the discovery phase, PMs work with the developers to approximate how long a piece of work will take. Ultimately, they have the final say since they are the one’s doing the actual work. Once the developer has committed, they have to deliver as agreed.
This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.
@adrian83
By the way, whilst I agree that it is hard to quantify the exact time to investigate and solve a problem it should not be used as an excuse to not get work done in a timely manner. Every successful business operates with tight deadlines, and a good PM can optimise the process so that the team is more efficient.
It sounds like you are making excuses for yourself when you can’t complete a piece of work quick enough. As opposed to looking at how you can complete it quicker which is where PM comes into play.
Besides, good reporting tools such as burn down charts measure the average work rate of the developer. If you have ever used one, you can get a good idea of the skill level and speed of the developer over periods of weeks/months based on the type of work that has been completed by the developer. So as a quick example, if the developer is completing 6 points of worth of story points on average over q period of 3 months, then that dips to 3 points for the next period of time and the tasks are similar. It is safe to assume that there is something wrong with the developer.
@SS
“This whole argument a non technical PM cannot measure performance is rubbish, if they take the approach above and missed deadlines happen consistently.”
In software development the speed at which a developer completes tasks does not equal with performance. A developer can finish his tasks pretty quick but his code most likely will be full of bugs and/or will contain a lot of technical debt that will make it very hard to maintain or further develop. Also code written in a hurry many times will suffer from performance issues.
Another developer may take longer to complete tasks but his code may be more efficient, less buggy, and much easier to maintain and further develop.
Of course there must a compromise between speed and quality but this is something that technical experts and technical managers are responsible for and not PMs (unless they are also very good technical experts).
If the technical experts don’t want to compromise on quality in order to gain on speed then there isn’t much non-technical people can do about it. Larger software companies however also have CTOs that are part of the executive management team and take all the high level technical decisions in order to put in practice the company decisions.
A non-technical PM will consider more productive the developer that finishes the tasks faster not taking into account the quality of the code and the impact the code will have on the future (bugs and technical debts). That’s why non-technical people or less technically competent people can’t really measure performance and usually are not responsible for doing this.
I am not sure about the way your organization works but I have never seen a PM responsible for the performance of developers, this is usually the job of a software developing/engineering manager and technical leads. Nonetheless PMs could be responsible for developing performance only if the are also technical leads.
@kp
Just to add only because you are technical does not mean you can manage people. I have worked with quite a few tech leads when I was a developer and in terms of management they were shit.
They had great technical skills, but that did not translate to having strong interpersonal, man management and planning skills. Both are needed to deliver a project in a timely manner. Again , please do not offend us by comparing us to ‘glorified secretaries’, yes we need to relay information And report on the status of the project, but unlike glorified secretaries we have to do a lot of planning to make sure everything is delivered on time managing cross functional teams. A secretary will never have this level of responsibility and experience the level of stress that comes with this ever!
As I said in a previous comment project managers, as a general rule, don’t manage people.
Managing people involves:
– hiring an firing employees,
– managing the work assignments of employees (for example on which projects they should work),
– providing technical leadership and guidance to employees,
– taking high level technical decisions,
– evaluating the professional performance of employees and taking actions to improve it,
– managing the employees rewards system (pay raises, bonuses, other benefits)
– sanctioning the employees for wrong doings.
Employees who are not themselves managers are managed by low level managers (also known as first line managers). These low level managers, as a general rule, don’t manage projects and don’t work as project team members instead they supervise the work of their direct reports no matter if they work on projects or not. Some low level managers have a budget at their disposal so they can act as project sponsors.
Also the low level managers in most cases are promoted from among technical experts as they do need their technical abilities to perform their work. If you are not a technical expert yourself how can you decide who is the best candidate to get hired to work in a certain technical role?
In small companies there may be no low level managers which means that the technical experts may report to someone that has not technical background, or does have a technical background but in a different domain. The above rule usually applies to larger organizations.
I am currently studying a Project Management module in College and all I can say is, hell will freeze over before I ever become a PM. Quite simply it would be my idea of hell.
Then why are you studying that shit? Use the money to study something more respectable and actually useful to companies.
I bet you have never worked in a company that has no serious project management or none at all to make that remark. Like any profession there are good and bad project managers, that’s why digital people hire them.
Lol, a housewife with 2 kids does more project management at her house. No studying required.
You know right that there are different styles of PM, Prince 2, Agile methodologies etc and the hard part is knowing what style of PM to put in place so that your organization runs smoothly? You clearly are a moron to be honest if you can’t see the value of good PM with helping a project stay on track and within budget.
Because it is a module in part of my overall major.
I bet that is the one class during which the students relax, sleep in class, or answer WhatsApp messages on their phone, because they need to be save their energies for actual Computer science subject classes like Data structures or Compilers.
Right, because the ONLY skill to run a successful IT organization are technical skills – what about keeping everyone motivated and being able to get non technical and technical teams to work together to deliver a project on time?
You my friend are a moron, and this is coming from a comp sci grad, that was an ex developer and now a PM. I can just tell right now that you would be an absolute nightmare to manage from putting people whose roles that you feel are unimportant down.
True about most my class sleeping. I’m voming from an experience of also having worked on projects in the past, and from what i have seen Project manager is the most undesirable job in a workplace. No way I could ever do it, becoming the most hated person in a workplace isn’t worth it.
If they are the most hated people in the work place then they are not very good from not gaining respect of the team they have managed. I have a lot of respect from the team that I am managing, since I make them feel very involved in the decision making process with upper management from voicing their concerns.
You guys need to stop generalizing, it’s like any profession, you have good and bad PMs. The good ones will have your back and shield you from corporate politics so that you can then focus on writing code without getting dragged down.
As said it’s my experience. My experience is that PM’s (that I have worked with) are the ones ready to bask in the glory of a completed project but when it’s delayed they are the ones to come in and tell you “Weekend’s canclled guys, overtime for everyone – or else”
You know what, that does happen, no doubt. But again, they are not very good PMs if they can’t plan the project and resources properly to ensure things get delivered on time. This is arguably the most important part of the role, and the whole point of being a Project manager to introduce processes so that work is delivered smoothly. Overtime is a massive red flag, and it is a sign that the planning was inadequate as well as expectations not being properly managed before the project begun.
At the company I work in, when a project is going wrong, I am the first one responsible for this. If it turns out that the project is delayed, because a member of the dev team is not pulling their weight around, then that is another story altogether. I have in the past worked with subcontractors who did exactly that, and we quickly found out through having good reporting tools in place (another must for any decent PM).
” they are not very good PMs if they can’t plan the project and resources properly to ensure things get delivered on time. This is arguably the most important part of the role”
Lol the way they do this is to ask developers how long a task will take, maintain a spreadsheet with cells that are colored red, yellow or green, then keep disturbing hardworking developers every day or so asking the status, and whether they are going to meet the timelines THEY came up with, and update the color of the spreadsheets. I could easily write a few lines of Perl script to emulate the work of a PM. Or train a chimpanzee to do that work, just for the lulz.
What you are describing is the classic waterfall project management, where the reporting is built around GAANT charts that is based on approx time. GAANT charts are often inaccurate since your forecasting is based on a developer opinion on how long something will take and not past performance as you have just found.
Any decent digital PM uses agile methodologies to run digital projects, where forecasting is based on the historical work rate of your developers (and team) breaking down work into user stories with story points allocated to them. Obviously, yes it helps if you are technical, but the role is much more about optimising team performance so that they are able to produce high quality work efficiently and consistently. The PM role in the whole process is to support the team, not get hands on and deal with impediments as they arise, ensuring the process is being followed. They also act as an interface between the stakeholder and the rest of the team. This means your developers can get on with coding and not be worried about being dragged into meetings talking about operations and strategy.
Anyway, I still stand by my point, you have just worked with shit PMs from the sound of it.
ROFL ok for what you described above, a few more lines of Perl code. You are redundant. ROFL.
Such a moron, really are.
Pearl won’t solve your problems when the team loses motivation to work, and thinks you’re an arrogant dick.
I love thrashing this PM guy online, for all the years of abuse I faced under PM after PM in my career.
So for the stuff you mentioned, in addition to my Perl code I could create a new role called mother-hen, hire a motherly looking woman, will sit in a “hugging room”, and employees could walk in and get a hug.
That is better than having these PMs trying to play a mother hen.
ROFL.
But seriously, we engineers faced tough engineering entrance exams at age 16 before joining college. We don’t need no empathy at work. We are self-motivated and are tough as nail.
You seem to forget that you are talking to a CS major which is why your arrogant engineering comments piss me off, I studied all your modules and coded professionally for a while.
You’re also deluded if you think management is so black and white – take a look at me and you right now, we are bickering because we have a different outlook with how things should be done. I.e. You are downplaying the importance of a PM, whilst I am not. Now imagine that situation in a company where you need to manage stakeholders, the team expectations so that they all follow the same page so that everyone is happy and it gets delivered properly. In short interpersonal, and leadership skills are not something an engineering class teaches you, either you have it or not. Since a company comprises of NON TECHNICAL people as well, it doesn’t always come down to how technical you are. The fact that you are so blind to this, goes to show that you lack leadership, communication skills and are a pure techie, hence why PMs have a job running operations.
Anyway, I have nothing to prove, just yesterday I found out that sales have increased by 60 percent from my delivery skills. Previously, they were taking your retarded approach and just having technical people with no project management experience run the show.
@underrated:
My personal experience with PMs has always been very good. They have always been friendly and many times show humility towards the other project team members.
With the exception of the less complex or internal projects I believe that PMs are very important for the complex projects that are being delivered to external customers. Trying to deliver a complex project to a customer without a dedicated PM is not impossible but it is very hard and very inefficient.
I am not trying to demonstrate that PMs are useless but I don’t like it when many of them are telling lies, usually on the web about the actual work that they are doing.
Many PMs claim that it is their merit that the project is being delivered in time and within budget but this is obviously a lie since they don’t contribute to the actual work being performed. What they are doing actually is helping the project team members to deliver in time, but they can’t do anything about it if the team members can’t do this.
They also claim that they are managing people. Managing people however involves hiring and firing employees, managing the employees work assignments (for instance on which projects to work), providing technical leadership and guidance to the employee, evaluating the performance of employees and taking steps to improve it, managing the employees rewards system (pay raises, bonuses).
PM usually have none of the duties above, what they are actually doing is managing the tasks that have be performed by ensuring that the tasks are being assigned to a team member or group of members and then monitor and report the progress. They also deal, or should deal with any non-technical issue that impacts the team.
They claim that they are planning the project but in reality all the information they use for planing is being provided by the other team members. If the other team members provide poor information then the whole planning will be poor and unrealistic.
They claim that they are motivating the team members but actually can’t do this since most of them have no power to give raises or bonuses. Of course money is not everything, employees can also be motivated by other means but it is hard to motivate someone to do something without giving him/her any material benefits.
Also many PMs consider themselves more mature than the other team members as if they are some sort of coaches or mentors. That’s again untrue since team members want from their coaches direction on how to perform their duties, something that most PMs can’t provide.
The biggest benefit that PMs bring is stakeholders management meaning that the PMs most be some sort of mediators capable of getting all the stakeholders involved in the projects to work together in an efficient way. Dealing with the customers is equally important and in average PMs are much better than engineers when they have to face the customers directly.
@adrian83, if you are referring to me, I am actually doing most of that in a support capacity. Being Scrum master I need to track progress, report the status of sprints (to stakeholders), and generally act as a support mechanism. Then again, I am working at a small company so probably doing a lot more than your bog standard PM. Yes, indeed when a project is going peer shaped I am at the mercy of the technical team, which as you have correctly support need to relay this back to the client as painlessly as possible.
I also do a hell of a lot of planning working with both the technical team and stakeholders. I don’t implement the features, but requirement gathering and maintaining a product roadmap is.
Ok this guy is a Program manager, to use the terminology in my company. Such people do some useful work as he says and don’t have any reportees under them. They are not the scum persons, and work alongside engineers without being involved in their performance appraisals.
The scums are the Engineering managers, specifically the ones that are non-technical. They will either do the same overlapping tasks with Program managers (or just steal their reports), or no work at all except playing mother-hen and shit, and the most preposterous thing is they are involved in performance appraisals, and give employee ratings purely based on who are their favorites, for they have no frigging clue about the actual work. These bastards should be fired, they bring a huge huge value to the company, with a negative sign in front.
IMO Program management is fine as long as they are not also people managers with reportees. But Engineering managers should do engineering or not exist at all.
You are so angry towards PMs, as a matter of fact I have got nobody fired after a year doing it, everyone I have ‘managed’, has ended up becoming better more productive developers, they have all also given me glowing recommendations on Linkedin. I do not also intervene with how technical teams do their works, as long as when they commit, they help me deliver it. Hence, they have a lot of say at the time on the initial planning, whether the work is realistic or not during the time frame. My role is basically to ensure everything is organised, and processes are followed (from top to bottom – non technical and technical). I do also come from a technical background so do provide technical support if needed from time to time. Recently a developer was stuck on a javascript problem involving callbacks, I helped him out.
@underrated – sorry misread it yes I am more of a program manager, or product manager as they put it. I am more interested in operations as a whole and making sure every one is happy and we are respecting the product roadmap for x quarter, y quarter etc, as opposed to caring about how developers write code etc as long as when they say they will commit to doing something they deliver. If it turns out after they have committed, issues have arose during the release cycle, instead of getting the guy fired, I escalate it to upper management, and produce a status report why we are having trouble delivering it. Sounds easy right – but it isn’t when you are dealing with aggressive impatient stakeholders. Account management is only easy when things are going smoothly.
I also have to do loads of other paper work such as producing a product road map so that stakeholders have a clear idea of how things are shaping up, requirement gathering (writing the user stories and acceptance criterias for the developers etc), research ways to help the product be more competitive etc etc It’s a lot of paper work – a developer can do this too, but it is a job in itself.
@underrated
Now I understand your problem. You have no issues with project/program managers but with functional managers.
Most companies operate under something known as the matrix organization. What does this mean? It means that all the employees are assigned to teams according to their line of work and function. For instance all the Java developers from a company or department may belong to the Java Team. QA Engineers may belong to the QA Team and so on. The head of such a team, or a group of related teams is known as the functional manager.
The activities performed by a company however require that workers belonging to different functional teams to work together as a so called cross functional team. For instance in a software project business analysts, architects, developers, and QA engineers need to work together as part of a team. These cross functional teams are typically temporary in nature (they only last for the duration of the project) and are being managed by project managers. The membership of the team can also vary depending of the project’s need.
Project managers however don’t manage the people that are working on the project teams but instead they manage the tasks that have to be performed, defining them, ensuring that they are being assigned and reporting the status to both management and customers. They also manage the communication between the different components of the team as well as between all the stakeholders involved in the project. Sometimes this is know as managing the operational aspects of a project. PMs generally don’t manage the technical aspects of a project.
Project managers however, as a general , rule are not superior to the other team members and they have no formal authority over them. PMs are just ordinary employees (not managers) with no subordinates. PMs don’t have the power to hire of fire employees, give them orders, do their performance appraisals, or manage their rewards system (pay increases, bonuses).
All of the above duties belong to the so called functional managers. An Engineering Manager is a functional manager for a team or several teams of engineers. The functional manager manages people and he/she is the boss while the project manager does not manage people and he/she is not a boss.
As a general rule functional managers should come from the same line of work as their subordinate employees. For instance the functional manager of a team of developers should be a developer too.
It appears that your company has appointed functional managers that are not from the same function as their direct reports, that is engineering managers that are not engineers. This is not typical as in most companies engineering managers must be engineers. If you look at job adds for engineering managers you will see that in almost all cases being an engineer is a must.
So you have issues with managers that have formal authority over you but are not from the same line of work as you are. These are typically not project managers.
@SS
Effort estimation in software development is something very inaccurate as developers are only able to truly appreciate the complexity of a task while they are working on it.
When you give a developer a task he will try to imagine what needs to be done to complete it and then he will rely on his/her past experience to come up with some estimates to which he/she will add a safety buffer.
A task however may have a lot of hidden issues that will only come up to surface after the developer has started working on it. If the buffer can cover these issues then the developer can finish on time otherwise he will finish later.
Also a task may involve working with some frameworks or APIs that the developers has never worked before. This will make the estimate even more inaccurate.
In conclusion developers can’t really commit to some deadlines for completing tasks as they can’t come up with an accurate effort estimation. In order to complete in time developers may write poor code that will result in a large numbers of bugs, poor performance and a lot of technical debt that will make the code unmanageable in the future.
If a developer hasn’t finished a task in the time he said he would it does
not mean that he is a poor professional that has to be fired.
@Adrian effort estimation is not supposed to be accurate, but when done right you can measure the complexity of something relative to another based on the developer technical ability, which makes it more accurate than forecasting via a gaant chart which is based on the time something that will take. I was a former developer, so lets compare the following examples
Task:
I want ‘hello world’ printed in the screen on bold
This is easy right:
hello world
to
Task 2:
I want a button, when you hover over it, it becomes twice it’s size and turns from black to red.
Now I don’t know for sure how long both tasks will take, I am going to guess, but I can compare both tasks, and know obviously task 1 is much easier than task 2, so I am going to allocate it less story points to task 2. Eventually, this approach is going to form the bases of my sprint planning, once I get an idea of how many story points on average a developer can complete in a week. So if I am consistently finding on average they can only complete 6 points worth of stories a week, I am going to plan my sprints based on the above approach and put 6 points worth of tasks in there.
When you use the above approach in a sprint setting, you quickly get an idea of what the developer strengths are weaknesses are. i.e. for example, you may consistently see a developer might find some tasks easier than other – I once worked with a developer who just found front end tasks harder than backend tasks from under developed Javascript skills. Hence the developer is really involved in this process and has a say how ‘complicated’ a task will be, if the developer cannot estimate at all, then the problem is often because the task is too large and not broken down into small manageable features. Which is something that I often have to do for them.
As an example a stakeholder could request that they want a report, where you can sort the columns, is ordered alphabetically, has pagination, and can be exported in .pdf format. The first approach could be to tell the development team how long it will take, and then expect them to deliver it in the timeframe they said they would. The second approach, and the more agile way, is to break down the requirement into pieces. Once you have done that, the team can then more accurately figure out the effort needed to implement each individual component, and then give a more accurate forecast to the stakeholder based on how many sprints are needed to implement, and test it. So…as a point, it all comes down to planning in the end, and not technical skills, knowing how to write good user stories is a skill in itself.
Your point about software development is false where it is impossible to estimate tasks, although there is a level of investigation needed, overtime when you have seen the problem before, with experience you have a much better idea how long or complicated something will be.
@SS
You approach is very simplistic and ignores a lot of crucial factors that usually come up when you are estimating the effort needed to complete a development task.
For instance, while I was supporting the applications of a customer a change request had come up for adding an additional report to an existing one. The existing report was triggered every weekend it was doing a very complex database query and then it was sending the results by email to all the users. What I had to do is add an additional query to the existing one.
At first sight the task looked easy to do, writing the code that would perform the query was straight forward. Since this was a task with low complexity the effort estimate should have been low. However, when I had started working on it I discovered that the existing code was extremely badly written which made it very hard to read and understand, and very hard to extend to add additional functionality. So, this was no longer a task with low complexity.
I took the drastic decision to refactor the whole code by rewriting it from scratch to allow it to become manageable. This of course increased dramatically the effort estimate and thus the time needed to complete the task. After I had completed my task new change requests came asking to add other additional reports. Thanks to my code refactoring adding the additional reports was done much faster.
If your “productivity” reports had been used, then they would have told that my productivity had dramatically decreased because I took such a long time to complete a task that seemed to be of low complexity.
Also, if a developer works for a long time on a certain part of an application his productivity will increase but if he moves on a different part of the application his productivity will decrease because he needs some time to get used to the new code.
But what makes software development effort estimation really hard is the creative nature of the work. When you receive a task, you will think on the algorithm and the API methods you are about to use for it but during development you may find out that your initial idea doesn’t cover everything and you will have to adjust it. Also, you can choose to work faster with the risk of creating technical debt, defects and low performance, or you could work slower and create a higher quality product. No matter how good an experienced you are there is also the option to work faster or slower.
In conclusion, the way you think about reporting, effort estimation and productivity in software development is very simplistic and doesn’t consider some crucial aspects. Your approach is suitable for the projects that involve trench digging or other types of work that are not creative in nature.
It is perfect normal sometimes for the so-called productivity of the developer to appear as it is decreasing but in reality, the developer is doing an extraordinary job in order to deliver a high quality product. It seems your reporting tools don’t take this factors into account and that’s why they are pretty much useless.
@adrian83
It’s simplistic because I used a simplistic example, but we are successfully doing it on a web application that has an API (built from scratch) which feeds data into an angular JS front end and CMS. We built the product in less than a year incrementally.
The key is to know how to break tasks down into smaller chunks and that requires a lot of planning and investigation well before you touch a line of code. Yes, that means the developer should look at the code base well before assigning story points to the task. This is called ‘system analysis’ as opposed to diving straight in. If you found out that the code needed to refactored after starting the task, that means you just did not do a good enough job during the investigation otherwise you would have found that out before committing to the work from looking at the code base.
It is also ok if you are not always accurate the point is that your forecasting will be a lot more accurate than if you have not done it. If it turns out you start a sprint and you are delayed because like in this case the initial investigation, and hence user stories were not broken down properly, then this issue is raised during the sprint to your scrum master where the plan of action is to then for the next sprint break the stories down further to manageable chunks. As opposed to committing to deliver everything in one go.
@adrian83, to expand on my last post, I just feel that you can’t not have any project management – the problem with your whole approach where since you are structuring the project based on very little planning (finding out as you go along) and timeframes, you have literally NO pressure to deliver in a timely manner. Furthermore, right now you can get away with not requirement gathering properly. Hence, with your current approach , you can exploit it and keep on telling stakeholders ‘it took longer than expected because of x and y reason’ from a lack of initial planning. In the end this may work in your favour, since you can dictate the pace work is delivered, but many companies have a product roadmap that they need to respect, and need to minimise delays as much as possible to keep their competitive edge.
No project management framework is meant to be accurate, but in the case of Scrum, the accuracy improves overtime once you have a better understanding of the product you are trying to build and the capabilities of the technical team. Most sprints are 1 or 2 weeks at a time, that is more than enough time to get a substantial amount of work done. Again, if you have stuck items into the sprint that can’t be done in a week, your requirement gathering is just not good enough since they should have been broken down adequately enough.
Burn down charts measure productivity, daily stand ups are used to find out impediments once the sprint commences. Impediments are good since they often lead to process improvement which in turn makes the process of delivering work more efficient.
I can whole heartedly say, that every project I have worked on as a developer where it was run with no structure have ended up always being messy ventures, where:
A) Stakeholders didn’t know the status of their developments and being met with constant delays.
B) team of developers slacking or not working in sync with one another, let alone hitting the company goals. They just didn’t care – they had no pressure.
C) release cycles being delayed , if a startup , company going more and more in the red paying for the delays.
Well as I have seen project management or indeed any other form of management, you will be hated by the workforce. It’s just part of the game. As the last PM said
“Yeah everyone hates me but the job get’s done and at end of the day that’s all that counts”
Only bad managers or bad project managers are hated by the “workforce”.
I have never had issues with project managers, on the contrary my relationship with them has always been very good.
However it is important to understand that project managers are not real managers as unlike real managers they don’t have any formal authority over other employees. The project team members don’t report to the project manager but to their line managers. Sometimes line managers can also do project management work but this is a different story.
PMs don’t have the power to hire or fire employees, don’t have the power to give them instructions on how to do their job, they don’t perform employee performance evaluation, and they don’t decide on pay raises or bonuses. That’s probably why they are generally not hated by other employees. Some of them however may get hated if they bother the employees with too much useless questions and drag them into too many long meetings that bring no benefits to the workers.
Real managers may be hated by some employees if they don’t reward their best performers properly or don’t allow them to grow in their career.
Both managers and project manager may be loved by other workers if they perform their duties right. For instance managers that enable the employees to develop their career and reward their efforts will be loved. Also project managers that take care of most of the non-technical issues of a project allowing the workers to focus entirely on the technical aspects are also going to be loved. :)
I am yet to work for any manager I didn’t hate. I’ve always maintained a distance, and view it as: If I don’t hear from a or seldom interact with a manager, all the better.
@Cal
Are you talking about project managers or managers with formal authority (such as engineering managers)? These are completely two different categories of mangers with different duties.
The project managers I have worked with were not real managers (they were not part of the management team) but ordinary employees and they sat at the bottom of the hierarchy. Some of them were not even permanent employees, but temporary employees or freelancers or contractors or consultants working for a consultancy.
These PMs had absolutely no power over me, other than formally approving the work the team has to work on. But they were usually approving the work by ensuring that the work is going to be payed. They were not involved at all in defining the work than needs to be done, in estimating the effort needed or deciding what exactly needs to be done. Their only obsession was for the work performed to be part of the project scope and get payed.
I see no reason why you would hate PMs such as these. Maybe if they bother you asking too many questions or organizing too many meetings that are useless.
Managers with real authority on the other hand can tell you how to do your job so you can end up hating them if they don’t let you do things the way you want it. But even here I had no issues.
Everyone in this discussion could use a good 3 years of experience in the technical systems side of a commercial construction project.
i would have to agree with Adrian33 on the software estimates. We recently moved to assigning the scope risk from the project budget to the development teams and moved from waterfall to agile.
We deliver fixed price, fixed scope, fixed schedule projects where our customers submit table of compliances. We have to comply and provide software estimates. Now that the Dev teams are doing the estimates, they estimate everything at 500 hours because they do not know the full scope. And as a PM, I cannot blame them. Then there is an internal battle over the price is too high vs please lower the estimate.
Agile is not for fixed scope fixed price projects (google it, no one in the agile world talks about it). why? because agile essentially acknowledges the variance of software. At the sprint level, once everything is broken down to the 20hr task, yes you have a higher probability of being accurate. But I guarantee you, you cannot do that when you comply to a customer’s one paragraph description of requirements.
what I have seen in the move to agile is two things:
1. Better meeting schedules for smaller items
2. Because the minimum point estimate is 1 which equates to 8 hours in our company, fixing small items get unrealistic estimates when aggregated together. Previously fixing small things would happen because they were one liner, but now these never get done
And with project planning Adrian is also correct, the plan is based upon input from the technical people. During my PM training, the instructor gave an analogy: ” I am a pilot of Cessnas, do you think I could fly a 747″ The whole class said yes, except for me. He asked why? I said “You would not know how to start it”. and this is the smae for a project schedule, The PM cannot create a schedule as he does not know the dependencies, but the technical people do, so why dont the technical people tell an administrative person and he or she create the schedule? Our PMs do way too much administrative tasks
I worked as a PM as part of a larger project where there was a Program Manager and I could not figure out what he did all day. Turns out he copied my schedule and had his own and kept asking me for updates. I told him I’d get my assistant to update his schedule based on mine.
It seems to me non technical PMs spend way too much time doing administrative tasks, and there is nothing a PM can do if the project is behind, except add more people, reduce scope, extend deadline. All which are contrary to the contracted deliverable (fixed cost, fixed scope, fixed schedule). The only decision he may(not necessarily) be able to do by himself is to have the work done with less expensive people (assuming they are of equal quality)
…and I have been a PM for ten years and I think we are overpaid.
Back to SS, why do you need to create burn down charts? why doesnt software do this for you automaitcally? All these reports are administrative. I did a test once to see who actually reads my reports. Some of them, no one. All anyone wants to know is if it will be done on time, if the answer is no, what can be done. If the answer is add more people, then someone has to make a decision on more cost.
And the bigwigs ask “why is it over budget”. answer just like someone else said, “once we got into it, there was more effort”, and then the response will be why didnt we quote it more, then the answer is, sales couldnt sell it at that price. Around around it goes.
Give me a simple user story. I can quote 1 point or 20 points, entirely dependent on the customer.
@JD
“It seems to me non technical PMs spend way too much time doing administrative tasks, and there is nothing a PM can do if the project is behind, except add more people, reduce scope, extend deadline. ”
I do a lot of that, and why is it seen as an easy job only because it is administrative? Let’s break that down to what is involved:
“except add more people”
The only way you are going to do that is if you have managed your initial project budget correctly, or are given the budget to do so which is highly unlikely since the budget is determined by the amount price the project has been sold at. Baring in mind, when you run most projects, you need to make sure that the company is making a profit, and need to sign off with at least a 50 or 60% profit margin, as is the case where I work.
Is this technical, no…is this always easy, again no, is this administrative, yes, but somebody has to sit down keep track and make sure the budget of the project is not ballooning. I find this more of an issue when you work with 3rd party sub contractors who charge by an hour than with an in house team.
“reduce scope, extend deadline.”
Ok again, the process of getting either done is to talk to the client, explain the situation and hope that they agree with you. What if the client is hostile and doesn’t care, what then? This is where it can become tricky. Again, not a technical skill, but account management. Maintaining client relationships however is extremely important since it can lead to more business which impacts the companies cash flow.
Ironically, these 2 things you have mentioned is arguably why a lot of companies hire PMs and pay good money for them. When you have a good PM and they ensure both are done properly, it helps the company generate a great deal of money since projects are signed off smoothly with good profit margins leaving a happy customer and more business down the line.
I am sure as a project manager, you have also managed a team of people to deliver a digital product at some point, designers, developers, testers etc all with different personalities and egos. What do you do if one person in that chain is a bottleneck? Are you going to expect you developer to go to the designer and tell him to hurry up? That is where it can be hard, and where I disagree with technical people such as Adrien is that they seem to think that they are the only people working on the project. Yes, if you are the only person working on the project, and nobody else then it is easy to manage since everything is down to you.
“1. Better meeting schedules for smaller items
2. Because the minimum point estimate is 1 which equates to 8 hours in our company, fixing small items get unrealistic estimates when aggregated together. Previously fixing small things would happen because they were one liner, but now these never get done”
a) Scrum which you use story points for, is not based on time, but the complexity of each task relative to each other, and you measure complexity based on burn down charts which is based on points. So when you say 1 points = 8 hours, that is not a great way of doing things. It should be this task is 1 point, the other task is 2 points, because from experience we know it is easier to complete than task 2.
When I plan my projects, I work out the average number on points the team can handle in a week, then base further planning on the average. You do not find this out until after 2-3 sprints from reading burn down charts.
If small things crop up that are not completed, I then have to sit down with the stakeholder and tell them the situation and more often than not those small tasks form the bases of the following sprint.
b) There is software that automatically generates burn down charts for you, but you still need to know how to analyze them to optimise the productivity of the team. That starts with knowing how to use story points efficiently. Ties in with your earlier question.
c) Fixed scope projects, with set deadlines don’t work well with Scrum, but you can run them in an agile way using Kanban. I would argue though if they are fixed scope and you have had no say in what the deadline will be, then it might as be classed as a waterfall project. The whole point of Agile, is so that you can deliver your projects less rigidly not set by an unrealistic deadline.
d) It is fine if the developers estimate how complex tasks are, I find where I am needed the most especially with product management, is helping the stakeholder scope their work properly so that only features that bring the most business value into their product are prioritised first. This is not technical, and involves knowing how gather requirements and write user stories, then prioritising them which goes onto form a product roadmap. If done well, your stakeholder will be happy since their expectations are managed from knowing what to expect from the upcoming developments.
e) Finally, yes, being technical helps immensely. I come from a web development background, I often use that knowledge when communicating with technical teams.
The more technical you are, the better PM you are going to obviously be, but at the same time where I disagree with Adrien is his idea that they need to be a specialist in that particular thing. As long as you understand what the problem is, how the technical team are going to try and achieve it on a high theoretical level. As a PM, I think it is important that you understand software architectural patterns, APIs, MVC, Server-client architecture. Knowing how one particular programming language works does not matter, that is for the developers to care about.
with respect to this:
d) It is fine if the developers estimate how complex tasks are, I find where I am needed the most especially with product management, is helping the stakeholder scope their work properly so that only features that bring the most business value into their product are prioritised first. This is not technical, and involves knowing how gather requirements and write user stories, then prioritising them which goes onto form a product roadmap. If done well, your stakeholder will be happy since their expectations are managed from knowing what to expect from the upcoming developments.
we have people, BAs , product managers, and architects who do this as they understand the customer’s business and the value it may or may not add. The only thing I can do is say, we are running behind, can you please prioritise. which then means I am reducing scope, or am now forced to deliver some now and some later, increasing my cost. As we moved to Agile, we discovered we now have a huge deployment, test, retest, do it all again cost, because it is all so fluid.
WRT to points and hours. At the end of the day people get paid by the hours they work and we have to quote to customers in dollars. if you estimate in points, there must be (and is) a correleation to hours/dollars. I know agile hates to talk in hours, but everyone will admit at the end of the day there is a correlation to hours. For us it is 1point is 8 hours. The complexity comes in in that they are not allowed to estimate, say 7 points. It is always(and I cant remember the exact sequence) 1,2,4,8,20,50. but as I say the small item problem is still there as they cannot estimate 0.5 points. so if I have ten one liners, they get quoted as 10 points or 80 hours, where before, we just would have fixed them in a day or two by the time we tested it.
That being said, I noticed now internally we estimate in hours for bugs, and estimate is broken down into investigation, fixing, testing, but all in hours
I was going to tell my story on why meeting the estimates can be so wild. I had the exact same dev team working on the exact same technology, but for two different customers, and with different features to augment our existing application. One came in at 50% margin, and the other at 12%. Why? Customer definition, customer expectation (my favorite “every good software should do xxx” or my other favorite, you show 3 decimals, anyone who writes software in this industry knows to show one decimal from that type of quantity)
and they simply will not pay until it is “fixed”. A customer with no internal need to meet a schedule date is the worst customer
Analogies are generally bad, but I give this one, if you ask me to paint the room blue, and I paint the ceiling blue, is that what you expected? what about the baseboard? door handle? shelves?
or the other easy analogy. The user story of : As a person who counts cars, I need a tool that I can add the number of cars as they go by. How many points?
Well, there is no definition of font size, no definition of it this application can run on top of another, no definition of errors, no definition of colors, no deinfition of whetehr or not a history needs to be manintained. could be anywhere from 20 points to 1000 points
The good news is you average all of them out and the company is close to the desired margin. The bad thing for us is if you end up with a few bad ones, you have a bad year as ours are large and not enough to go through enough to average out in a shorter time period
@JD
I can see a few problems here:
1) In your case, story points does not seem to be being used in the right context. It sounds like you are substituting hours by points for projects which have short delivery cycles i.e. need to be delivered in hours as opposed to a period of weeks/months. There is nothing wrong with associating time with story points as long as it is loosely done, for example for 2 points I’ve allocated a day to it, for 1 points half a day etc.
In your case, and if story points is being used how I’ve assumed it is, you are better off organising your project using Kanban and not Scrum which uses Story points. You can then measure productivity using ‘cycle time’ i.e. the time it takes to complete a requirement based on the time it took to complete it. This is another agile methodology, but more in line with waterfall I guess.
I have found that the real power and benefit of using story points is when you have structured your project integrating Scrum. Projects that benefit from Scrum are typically those that do not have to be delivered immediately but over a period of months/years.For those projects, the idea is to deliver the project scope incrementally in weekly or fortnightly sprints, where the work for each sprint is planned before the start of every sprint according to the what gives the most business value for the stakeholder at that particular time, and the work rate of the team is measured using burn down charts based on the story points allocated to the tasks that comprise the sprint.
A real life example of the type of project that benefits from this approach, is when you are tasked with the on-going delivery of a new product to market, since an attribute of product management is on-going development of the product based on new ideas that appear overtime.
It is worth noting, as every project is different, the velocity of the team on one type of the digital project is not necessarily applicable to another, given that every project is different. So it should be expected for the first few weeks, that the teams will fall behind on the burndown charts whilst they get used to the project. The way to handle this, is to decrease the total number of weekly story points until they hit their target, then gradually increase as they become more comfortable. After that initial hump, it does become easier, with more accurate forecasting as a result.
The end goal by doing things this way is that once you understand the teams velocity for that particular type of project. You can then give a more realistic time estimate of when things will be delivered rather than plucking a figure from the air and saying ‘it will take 3 hours’ since your forecast is based on what the team can do from experience as opposed to what you think they can do. That’s why I would never use hours to specify the time needed, but measure the deliverable based on the number of sprints it needs which is a lot better way of doing things given the time needed to implement, test, QA, release.
If put in a situation where I need to deliver work based on hours, I would not structure my project using story points and scrum.
WRT this point:
“I was going to tell my story on why meeting the estimates can be so wild. I had the exact same dev team working on the exact same technology, but for two different customers, and with different features to augment our existing application. One came in at 50% margin, and the other at 12%. Why? Customer definition, customer expectation (my favorite “every good software should do xxx” or my other favorite, you show 3 decimals, anyone who writes software in this industry knows to show one decimal from that type of quantity)
and they simply will not pay until it is “fixed”. A customer with no internal need to meet a schedule date is the worst customer”
The problem here is not story points, agile it is bad requirement gathering. That is not your fault, your BA is not doing a good enough job and causing you to struggle with project delivery. If S/he did, you would know exactly what needs to be delivered, which brings me to your next point based on the analogy:
“Analogies are generally bad, but I give this one, if you ask me to paint the room blue, and I paint the ceiling blue, is that what you expected? what about the baseboard? door handle? shelves?”
Good user stories should have user acceptance criteria’s which covers what the end user expects from that ‘story’. In this case, the user story would be:
As a user, I want my whole room to be painted blue, so that it is a different colour’
User acceptance criteria for the above story will be:
– Ceiling must be painted blue
– All of the walls must be painted blue, there are 4 walls
– The wooden door must be painted blue
and so on. If the user acceptance criteria has been fulfilled, then the story has been completed.
Where it gets tricky however, and I think that this is where you might be struggling is not only from a lack of user acceptance criteria, but from the stories not being broken down properly. So using a software development example:
“As a user, I want a report which displays people that have registered, so that I can see who has registered”
That is not a good user story, because it doesn’t tell you what the sub features of the report are. i.e. can the user sort the rows in the report by column? Can the user export the report etc, if so , which format? So for argument sake, lets say the client wants a report which displays all registrations, where as sub features you can export the report and order it by columns. You would create 3 user stories:
Story 1
As a user, I want to see a report table which contains all registration data, so that I know who has registered.
Story 2:
As a user, I want to be able to sort the entries in the report table by column, so that I have more than one way to view the data
Story 3:
As a user, I want to be able to export the table in the report in pdf format, so that I have a copy of the report.
When you do this, it then becomes easier to allocate story points since you have sliced the functionality into smaller chunks.
I will try the kanban, sounds promising.
I do think you may have missed the point on the scope definition. We have two types: 1.we have to comply to table of compliances, where there is no(or very simple Q&A) negoitiation on scope.
2. where we work with the customer to get user stories, usually by a BA, product manager, architect (not the PM)
1. is problematic simply because the specification is usually abstract, but the customer will continue to say “this is your busniess, you should know what this means”. I wont go into that one
2. is where we think we should be good but this is where I suggest the customer influence and agile(or maybe just software requirements in general) is lacking.
Take your example of a report. I dont see a user story for how many pages it is. I dont see criteria or a user story for what happens when the person’s name is 70 characters but you only have space for 50? Excel has two options, cut it off or make the font smaller. When your developer makes the report has has two choose one of these. why isnt it in the user story or criteria? The answer: Because the BA did not think about it(because he is not the developer), and that is my point. no one thinks about everything. And some customer will not care or not have that problem. And that is the variance in the software estimate
@JD
From what you have written, I feel that where the whole problem is stemming from is the requirement gathering and how it is being done. It just sounds like the user stories the BA is writing is not detailed enough, and this is having a knock on effect on your ability to deliver work from not properly understanding what the customer wants.
I am a digital product/project manager where I currently work, so I do all of the requirement gathering which helps a lot.
WRT this point:
“Take your example of a report. I dont see a user story for how many pages it is. I dont see criteria or a user story for what happens when the person’s name is 70 characters but you only have space for 50? Excel has two options, cut it off or make the font smaller. When your developer makes the report has has two choose one of these. why isnt it in the user story or criteria? The answer: Because the BA did not think about it(because he is not the developer), and that is my point. no one thinks about everything. And some customer will not care or not have that problem. And that is the variance in the software estimate”
It was a basic example, so I did not bother going into that much depth. But if I was doing it for real, I find that the best way to requirement gather is to start off with creating mock ups of the application working with a UI/UX designer, present that to the client and break each functionality into user stories which has low level user acceptance criterias. It’s the BA’s job to ask as many questions as possible so that nothing is missed out.
Once the client has approved the mock ups, it should be documented in a statement of work report, so that if later on the client asks for something beyond what was agreed, you can always remind them that it is not in the project scope and not initially agreed, but if needed can do it for an additional cost of x amount. A PM has to cover their back at all times, it is as you have said a highly political job which is what makes it hard. On one hand, clients are going to always push their luck to get work done for free, and then you have the battle of your team not doing their job properly – the BA for example.
Finally, to do agile properly, the whole company needs to run in an agile way, not just you. Not being able to negotiate project scope, with other people setting deadlines for you (from the sounds of it is happening) is not working in an agile way. The whole point of agile is the very definition of the word ‘agile’, to be able to adapt the project based on changes to the project scope at any point. Either by decreasing on increasing the scope based on the time remaining.
If the scope is defined and you have a fixed time frame, then you might as well forget running your project in an agile way but stick to the waterfall approach and use gaant charts.
i guarantee you, you or the well heeled BA will miss the 70 character problem, or the fact that there are 25 rows in a daylight savings day, or that it prints on two pages when I select printer x.
This is my point: If the code written has 100 if else statements, then the user story must have the same number. The reason: Because the developer is making a decision. And if there is no user story, what is he basing his decision on? If you are like us, it’s what the last guy did in a similar situation.
Who says that is what the user wants?
The mockups are good, and we have done many but they for instance don’t tell you the 70 character problem or if the sum and avergaes at the bottom of the page are rounded before summing or summed and then rounded. They dont tell you if the time has to be corrected for timezone. They dont tell you if timestamps represent the top or bottom of period. They dont tell you that the titles need to change for language when I am reporting on a person from a different country
What does this mean? This means you will have deficiencies which are not documented in the requirements. You will say, well the client didnt tell me, and the client will say you didnt ask.
You will win some and you will lose some, but in the end the variance of the software delivery is still there.
unless the developer checks all of the possible error conditions and code paths with the customer, there will always be a variance. And I gurantee you, the customer, nor the BA know all the code paths and data variations
@JD
“What does this mean? This means you will have deficiencies which are not documented in the requirements. You will say, well the client didnt tell me, and the client will say you didnt ask.”
It is the clients fault if they didn’t tell you, not yours. You should charge them for it, otherwise if you go down that path, they will just end up taking advantage of you from keep on using it as an excuse. I once worked with a client that did that, then stopped once we started charging them for every little thing.
It is always a good idea to send them a copy of the statement of works before any work has begun so that they can read how the requirements have been documented.
so, does your SOW state all of the above? i.e. peoples names will only be allowed to be printed up to 50 characters and we will truncate the left most characters until they fit? If so, great, but I’ve never seen it.
And it is the clients fault if you assumed 50 characters if you didnt tell them?
My client would say, why did you assume 50, his birth certificate has 70, I’m not paying because you decided 50 was a magic number you pulled out of the sky. now if you told him you only do 50 and even better asked him to check his data to see if 50 would work, then he will praise you for knowing “his business”. If you charge him for everything you did not document about your assumptions, he will not come back to yo as he would rather work with someone who “has done this before” and seen these types of things.
@JD
Again, if the client did not tell you that you have every right not to be held liable for not doing it. The whole point with sending them the SOW before starting their work is for them to double check that nothing is missing. If they double check and then bring it up later then that is not your problem. If your company makes it your problem, then I’m sorry to say they are a terrible company to work for. Where I work upper management takes my side in these circumstances.