But how could "pick the right" people possibly work out for everyone? Maybe some higher paying / more prestigious companies can do that.
But that would still leave the other companies with the original problem and not change anything about the industry wide statistics / problem?
However, the author also points out training. So changing the quality of education and the culture around the people can drive this into a better direction.
The two "under-performing" types I encountered where "hard to work with" and unskilled.
Unskilled but smart is not a big problem as long es there are some more senior people. They might not get that much done, but they are still net positive :). And of course they improve if you can hold them for a longer time.
People really hard to work with on the other hand are a tough nut and can hold back projects. I think this is often bad hiring. At least a company I worked for hired because they couldn't find anyone better (for the budget) and it turned out to be a big mistake.
Either way, you have to live and calculate with what you have.
If you do product work however I don't see why deadlines are all that important and would rather focus on the small, most impactful next iteration.
Hard to work with may dissolve if management set a good culture where everyone meet on even terms. Having a few hold all the keys to the kingdom scales badly.
Haven't made that experience. I worked in really good cultures where I loved the teams, but that can't always remedy the situation.
It's just a drag on everyone: Nobody wants to work with that person, they fail to communicate important things, there are pointless discussions. Even honest communication, mutually agreed on workflows and so on can't always fix things.
If you’re doing software product work I’m totally with you on small impactful iterations. When you’re delivering a hardware product this is a lot more difficult to pull off.
There are definitely ways to take an agile approach to hardware development, even if you’re working with an OEM, but the outcomes look a lot more like waterfall than your typical Agile with a big A people are comfortable with. The outcome of your iterations are long specification documents (which you’ve already got feedback on from your OEM), and a lot more detail than you’d typically go into development for on the software side since it has to integrate with the actual hardware.
Right, I also like waterfall for bigger projects with fix requirements at the end.
In fact I also mix agile with waterfall. So much easier to keep adjusting your requirements for a few milestones ahead than to scramble together stories to fill the next sprint every other week.
I still don't get why most of the recruiting process is left to the HR department. I get they objective is to minimize your distraction as a manager, but it's such an important part of building a good team and it feels that in many cases you (the manager, not necessarily PM) contribute like 20% of the whole process.
I recently was part of the hiring process for the first time and it was 80% the team, 10% me and 10% HR/boss doing the decision. The person we hired is absolutely awesome :)
Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.
Maybe it becomes time to change that. Less innovation and more repetition could help here. I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it.
We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
> I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it.
At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends.
I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
Physical projects have a construction phase, because they don't have the luxury of zero-cost copying. If you want to construct two identical houses, you still need people to lay bricks twice. If you want two identical websites, you deploy the same files twice.
By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
That's not entirely correct, given that most software projects tend to deliver new versions of something that already exists. Maintenance releases generally tend to be successful.
It's new projects that are hard and often have disastrous failures or cost overruns. I don't think software is unique in that regard. The Berlin Brandenburg Airport [1] and the new SF Bay Bridge [2] are cases in point. The latter included serious concerns about the integrity of the bolts that secure the East end of the suspension cables to its pier.
He seems to be pushing his book and possibly at the end his school:
"Years ago I wrote a book – IT's All about the People: Technology Management That Overcomes Disaffected People, Stupid Processes and Deranged Corporate Cultures – that focused on the human element in technology. The premise is as correct today as it was then."
Projects are hard and deal with the unexpected. If you've never done anything like whatever you are trying to do before, you will encounter delays. These are really not failures -- in fact a lot of projects are "finished" with many additional "add on" pieces and enhancements scoped for future work.
Tellingly, companies that do the same thing over and over again (video game companies come to mind), are actually pretty good at delivering on time and on budget. With a stable and experienced workforce, the right corporate culture and reusable work breakdown structures, it's all possible.
This is an incredibly well written review. Much better than the linked article, which is derivative, vacuous, and full of typos.
> Training should be re-invented around practice. Project management residents should learn how and what to do to manage projects successfully, and just like the medical profession, bad project managers should be washed out of their residencies.
This seemed to be the only novel idea in the article, and it comes at the end, and is never explained.
I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I know HN loves to talk about how much the PMs they've reported to suck, but having worked with many clients on dozens of projects, it's rarely that simple. While bad PMs are definitely way too common, so are bad development teams. And remember that PMs are usually getting shit on from two directions at once (development teams and management teams) with often very little authority to actually fix things. It's usually bad management practices and attitudes that sink projects and make life hell for everyone, and the cause of that is usually lack of understanding and empathy for how software development works.
The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.
If management don't understand the projects, and they generally don't, what are they really managing? Oh yeah, get the pay but use position as shield and sword.. You'll see the few exceptions are acting more like a PM, on and off.
> If management don't understand the projects, and they generally don't, what are they really managing?
With the inception of Agile, by definition software projects are impossible to understand in the sense of having a clear idea regarding concrete goals and risks, technical designs, and timelines.
Yet, you will need to manage resource allocation, plan tasks, eliminate risks, and coordinate between stakeholders.
The consultants behind AM are always hired by managers. I'm sure they agree what they do get for the money. Also being in same team with a stakeholder, you minimize coordination cost and adjust goals and plans according to value. The only thing with Agile, is there's no room for a management class inside such teams. So yes, empowering the team with all those responsibilities, this puts more in the hands of the people providing actual solutions. Though, the paperwork can be handled by staff.
Managers facilitating this will be more like an overall PM for multiple efforts. This across functions, as that is how you can get most value and improve culture. Such work is actually worth higher compensation too!
> Also being in same team with a stakeholder, you minimize coordination cost and adjust goals and plans according to value.
I'm not sure we are on the same page regarding what "being on the same team" means, and thus what the problems and challenges are.
Agile argues in favour of shared responsibility through the direct participation of stakeholders.
Yet, that does not mean that clients and product owners and team leaders and junior developers don't have goals and responsibilities and resources that need to be otimized, and more importantly that there is no accountability.
In agile you still have different stakeholders with their own goals. You still have work that needs to be done and prioritized. You still have to decide what needs to be done in a given time frame. That's what a manager does. Agile does not make that go away.
I only take some issue in last two paragraphs. I'll only mention for Agile teams, not other kinds:
In Agile team, the team is responsible. Management decides how to reach accountability, though in practice the team together can pull through more.
Agile team wants stakeholders in team, or close to team. Team plans work according to agreements with stakeholders, but can never ever be forced to do anything against their explicit agreement. Which is why there's no room for management on the team.
Agile teams sets managenent in their rightful place, and may work well when workloads, accountability and additional complexity are balanced within reason. Ensuring this for org, is too big for each team (indians). So chiefs are still needed around.
Vs projects: Agile teams isn't suited in all circumstances. There might be important stakeholders, costs, dates, hard known requirements, regulatory and coordination needs, that makes projects more suitable methodologies. Projects are temporary and manager-lead (PM on team), however.
Having a manager or PM in team though, isn't an Agile team. You need servant leaders on team, and managers wield too much power and information imbalance.
It's not about not understanding the projects, it's more often about misaligned incentives. In most companies project work is the exception compared to "everyday functioning" of the company, and the line managers are managing that instead; and a typical situation is where particular resources are needed for the success of the project, but they're also needed for the non-project things that the particular manager controlling that resource cares about and is evaluated upon, so it's in their best interest to prioritize other things at the expense of that project.
Or that manager might need a particular narrow subsection of that project done their way and the rest of the project is worthless to their goals (i.e. the very common 'silo thinking' in many organizations), so they might assign resources for that part of the project and 'starve' it afterwards. Management and internal politics has a big effect on which things get done and which don't.
Traditional line managers lack interest / incentives for projects. Even though they might be high priority, different functions have different goals and measurements. The managers themselves fail every new line initiative, since they've no project / PM experience too, and also no support or real budgets. When this happens, look at the environment though for answers.
This type of managing is running out of time, as it simply doesn't work that well beyond managers having eachother's backs. Managers need to involve themselves much more around projects / Agile, than just borrowing and stealing back "resources". If they can't provide servant leadership skills and healthy repurposing of roles, they need to stay away and clear blocks, allocate funds and people, from quite a distance.
> The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales
It's turtles all the way down. So, let's think about executive sponsors here. Why do they change scope and requirements? Why do the act the way they do?
Yes, there are executives who's career trajectory is defined largely by luck rather then acumen, let alone being knowledgeable or empathic to those in their service, or the stakeholders whom they cater to. But that's not the entire story.
Businesses, whether a small 2 man outfit or billion dollar enterprise, do not operate in a void. Their behaviour is very much driven by changes in their environment. Whether that's the markets they are active in, customers they target, labour markets they tap into, competitors innovating and bringing new products and services to market, and public governance issuing a changing legal frameworks.
Changes in scope and requirements are par for the course. Executive sponsors perceive those as investments and try to make risk-benefit trade off's assessing the information they have at hand. This is where uncertainty seeps into the decision making process. Even with clearly quantified information, it's still hard to predict the future. How will markets evolve? What do customers want? What will the competition do one or two years out?
Strategic thinking and planning is hard because of uncertainty. In a military context, this is a clear given for leadership. Helmuth Von Moltke the Elder (1800-1891) famously said:
> The tactical result of an engagement forms the base for new strategic decisions because victory or defeat in a battle changes the situation to such a degree that no human acumen is able to see beyond the first battle. In this sense one should understand Napoleon's saying: "I have never had a plan of operations." Therefore no plan of operations extends with any certainty beyond the first contact with the main hostile force. [1]
> we need better management training in general for anyone whose job is dependent on software
For sure, leadership training is an established need. And it's also a thing that is catered to. There are entire libraries, fields of study, management courses and so on dedicated to leadership training. There's no lack of options out there. That's not the issue.
More interestingly, you have to first question how executives ended up in a leadership position in the first place. For instance, many leaders don't necessarily became leaders because of innate qualities that show a due sense of what is understood as "being a natural leader", but because they were born into a context that handed them the opportunities that put them on that trajectory. Do note how I say "many". The above isn't a catch all either. How individuals end up in a leadership or management role is really a matter of many complex factors and happen stance.
And so, having a social studies background, I always tend to be a bit weary when I see the "we need..." argument because (a) the "we" is never specified, (b) the "we need" negates complex contextual factors and (c) it reduces the argument into a single problem that can be resolved in general terms with a single pragmatic solution.
And so that brings me to this point:
> usually lack of understanding and empathy for how software development works
I feel this goes both ways. Trying to understand the reasoning or the why behind shifting business strategies, and realizing that these are driven by fallible human beings who make mistakes based on incomplete information goes a long way. Working towards improving software development practices is a a great goal, but good will never be...
We just onboarded a new PM with loads of experience. I was very skeptical at first, but within 3 weeks I was being kept honest by this new manager on our daily calls. I didn't realize that we've never had a "good" one and how amazing it might be.
I feel like the process for building your software is more important than the software itself. I.e. How can you worry about building cars when the factory that produces them is burning down, or experiencing a work stoppage because no one ever thought to develop a maintenance schedule for a particularly tricky piece of equipment?
The more I look at this whole enterprise of software engineering as a virtual factory floor, the easier it gets to draw analogies between developers and project managers regarding how we should manage work.
Something that always seems to get missed is successful projects are linked to motivation. If everyone in the project is motivated to make it a success it's more likely to be.
Use an old technology none of the programmers are interested in and they go find other jobs or not work very hard as they put there efforts into their more interesting side projects..
As an example, projects linked to fulfilling legal requirements normally succeed because the motivation is strong - failure = fine/prison time.
Most projects I've seen failure where senior managnent doesn't want the project anymore but need a way of getting rid of it while saving face. Classic way is to pass the project onto another department...
I've observed and participated in a reasonable number of projects, both IT and otherwise. In my experience there are two problems that seem to exit in every project that either failed or had to go on to life support:
1. The deliverables were not clearly defined and maintained.
How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep.
2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project.
How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system.
Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working.
If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.
> People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project.
I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not.
In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt.
After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project.
This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.
> [Research shows that] Only 58% of organizations fully understand the value of Project Management
> Why do only 58% of companies value project management?
Well, that seems to be taking the research totally out of context in the first paragraph.
And then just rambles on about having great people, and having them really well trained in project management. Wow, who would have thought being good at project management and making people better at project management was the solution to getting better at project management!?
"Is scope creep the problem? No, thats just a symptom of people again, and training. Did I mention I have a book?"
Maybe I'm just cynical here, but there doesn't seem like too much insight here.
“I wrote a book on how PM is hard. It starts by hiring the right people. Of course, I wrote a book detailing how all the people involved at scale keep screwing it up. Buy my book.”
This a circular advertisement for a book.
I am guessing it’s more to with how most organize socially for human emotional reasons first and tacitly don’t give a shit about ephemeral nonsense except to play “Society: The Board Game”.
My pet solution is to use traditional MVC frameworks like Django, Laravel, use Bootstrap stock themes for style, and sprinkle in specific JS wdigets as needed. This will (IME) make day to day work much less chaotic. The chaos of changing business requirements will be amplified when we reimplement API and React for every page and errant JS breaking even scroll.
If I can dream, non-tech guys can only mention high-level goals based on data than interface. Instead of the mandate "in one day, reimplement snazzy chart from slick app...", tell "show top 5 contributors" and tech guys can provide an economical solution first and iterate on it later.
It's true that leadership is the key. Projects are successfully lead, not managed.
This means leading those above too: getting more resources, communicating and managing expectations
The nature of projects is that they're often one-offs or something that the company hasn't done before. So unless you're being very generous with time, scope and quality estimates you're likely to be way off because of optimism bias
Reading this article calls to mind von Tiesenhausen's Law of Program Management: "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."
I'm going to go out on a limb and say that smaller project are a possible solution. Do less and deliver something.
I've just gotten off two, multi-year projects, the first crashed and burned due to a mismatch between business process, vendors and the skills in the organization to understand what it does and translate that into requirements.
From the development side, we made a lot of stuff. Most of it was junk.
The second project arrived at a point underdone. Unable to replace the existing production solution because of a lack of a burning deck. I'd put this down as a failure as well. Mostly on the strategic leadership side.
In the meta sense these projects weren't that bad. People got money for doing them, and that money was spent in the economy.
Maybe Amazon is onto something with their two pizza teams, and 7 page proposals.
Smaller teams, and product management should be done by the development team. This will only work with at least some experienced developers on board who have shipped something before and had to deal with the results of that in production as well. For dedicated product managers the risk is high that the person does not know enough about the product or development. This is especially true in organizations where product management is an "easier" career path compared to development.
Poor article in my opinion. The problem described in the article is very true. But the solution, “focus on people”, is mostly tautologic and doesn’t explain at all what makes some projects successful and not others. I’m disappointed.
A key elephant in the room in this article: if it's just about hiring the right people, why is that so hard? Because most companies treat technology as a cost center, not a profit center.
Even for companies where that's the case, treating technology like a cost center is like treating legal as a cost center -- existential company killing risk goes way up if you don't pay for the real deal. And for companies where it isn't, you'll just flat out waste your money. Pay for a Yugo when you need a big rig and you'll get exactly what you paid for, which won't be what you need.
Maybe you should stop thinking your stupid L33T coding interviews will get you the best engineers. And actually interview your engineers for stuff that matters.
Like how they achieve redundancy, resilience, and fidelity in their software development.
And also, get some managers with half a brain, to understand that changes to the requirements can affect development efforts.
From my experience it all comes down to budget. If IT is a cost, then the ideal thing to do is to deliver while minimizing that cost (duh!). When you do that you get solutions that are the quickest and cheapest thing at that moment.
This actually has further impact on other projects because everything is done badly.
My question is, I wonder how Apple does it. Or May be Netflix. I think that is the only two in FAANG that is any good in product / project at a large scale.
Apple brute-forces it. They announce or decide to announce a release and do what's needed to meet that date. Netflix relies on people being driven to do the right thing with the consequence that those that don't deliver will be shown the door.
Projects fail because you have misaligned incentives. The CEO gets a pat on the back when he announces a Technology Modernization project, The Executive team gets a pat on the back when they negotiate 20% off the Modernization Project with IBM. The IBM salesman gets his commission as soon as the deal is signed.
Then when the project fails everyone blames someone else. If you want the project to succeed tell all those people that they will get their reward at the end of a successful project not before it has even started.
Tech projects should be easy to manage buy it fails due to,
1. Because of time sheet. It's either not tracked or questioned or sometimes it's questioned too much.
2. PM is not technical and believes the story being told.
3. PM calls for a meeting and asks for status but doesn't go to each people to collect information who is delaying or is he waiting for someone else's input. Flow is cut somewhere.
4. With sprints, too many managers but all sprints are handled by few Dev's, DBAs and testers.
5. Project changed its course into a discovery journey and everybody is too focused on the side track.
55 comments
[ 3.0 ms ] story [ 111 ms ] threadHowever, the author also points out training. So changing the quality of education and the culture around the people can drive this into a better direction.
Unskilled but smart is not a big problem as long es there are some more senior people. They might not get that much done, but they are still net positive :). And of course they improve if you can hold them for a longer time.
People really hard to work with on the other hand are a tough nut and can hold back projects. I think this is often bad hiring. At least a company I worked for hired because they couldn't find anyone better (for the budget) and it turned out to be a big mistake.
Either way, you have to live and calculate with what you have.
If you do product work however I don't see why deadlines are all that important and would rather focus on the small, most impactful next iteration.
It's just a drag on everyone: Nobody wants to work with that person, they fail to communicate important things, there are pointless discussions. Even honest communication, mutually agreed on workflows and so on can't always fix things.
There are definitely ways to take an agile approach to hardware development, even if you’re working with an OEM, but the outcomes look a lot more like waterfall than your typical Agile with a big A people are comfortable with. The outcome of your iterations are long specification documents (which you’ve already got feedback on from your OEM), and a lot more detail than you’d typically go into development for on the software side since it has to integrate with the actual hardware.
In fact I also mix agile with waterfall. So much easier to keep adjusting your requirements for a few milestones ahead than to scramble together stories to fill the next sprint every other week.
We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends.
I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
Slowly but surely you won't be able to hire new people into the team and your development won't be as efficient as in newer technologies.
But what is left is still discovery/inventive work.
That’s because in software, anything repetitive gets factored out into libraries and platforms.
It's new projects that are hard and often have disastrous failures or cost overruns. I don't think software is unique in that regard. The Berlin Brandenburg Airport [1] and the new SF Bay Bridge [2] are cases in point. The latter included serious concerns about the integrity of the bolts that secure the East end of the suspension cables to its pier.
[1] https://en.wikipedia.org/wiki/Berlin_Brandenburg_Airport#Ove...
[2] https://www.wnyc.org/story/316201-brief-history-64-billion-b...
"Years ago I wrote a book – IT's All about the People: Technology Management That Overcomes Disaffected People, Stupid Processes and Deranged Corporate Cultures – that focused on the human element in technology. The premise is as correct today as it was then."
Projects are hard and deal with the unexpected. If you've never done anything like whatever you are trying to do before, you will encounter delays. These are really not failures -- in fact a lot of projects are "finished" with many additional "add on" pieces and enhancements scoped for future work.
Tellingly, companies that do the same thing over and over again (video game companies come to mind), are actually pretty good at delivering on time and on budget. With a stable and experienced workforce, the right corporate culture and reusable work breakdown structures, it's all possible.
> Training should be re-invented around practice. Project management residents should learn how and what to do to manage projects successfully, and just like the medical profession, bad project managers should be washed out of their residencies.
This seemed to be the only novel idea in the article, and it comes at the end, and is never explained.
The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.
With the inception of Agile, by definition software projects are impossible to understand in the sense of having a clear idea regarding concrete goals and risks, technical designs, and timelines.
Yet, you will need to manage resource allocation, plan tasks, eliminate risks, and coordinate between stakeholders.
That's what a manager does.
Managers facilitating this will be more like an overall PM for multiple efforts. This across functions, as that is how you can get most value and improve culture. Such work is actually worth higher compensation too!
I'm not sure we are on the same page regarding what "being on the same team" means, and thus what the problems and challenges are.
Agile argues in favour of shared responsibility through the direct participation of stakeholders.
Yet, that does not mean that clients and product owners and team leaders and junior developers don't have goals and responsibilities and resources that need to be otimized, and more importantly that there is no accountability.
In agile you still have different stakeholders with their own goals. You still have work that needs to be done and prioritized. You still have to decide what needs to be done in a given time frame. That's what a manager does. Agile does not make that go away.
In Agile team, the team is responsible. Management decides how to reach accountability, though in practice the team together can pull through more.
Agile team wants stakeholders in team, or close to team. Team plans work according to agreements with stakeholders, but can never ever be forced to do anything against their explicit agreement. Which is why there's no room for management on the team.
Agile teams sets managenent in their rightful place, and may work well when workloads, accountability and additional complexity are balanced within reason. Ensuring this for org, is too big for each team (indians). So chiefs are still needed around.
Vs projects: Agile teams isn't suited in all circumstances. There might be important stakeholders, costs, dates, hard known requirements, regulatory and coordination needs, that makes projects more suitable methodologies. Projects are temporary and manager-lead (PM on team), however.
Having a manager or PM in team though, isn't an Agile team. You need servant leaders on team, and managers wield too much power and information imbalance.
Or that manager might need a particular narrow subsection of that project done their way and the rest of the project is worthless to their goals (i.e. the very common 'silo thinking' in many organizations), so they might assign resources for that part of the project and 'starve' it afterwards. Management and internal politics has a big effect on which things get done and which don't.
This type of managing is running out of time, as it simply doesn't work that well beyond managers having eachother's backs. Managers need to involve themselves much more around projects / Agile, than just borrowing and stealing back "resources". If they can't provide servant leadership skills and healthy repurposing of roles, they need to stay away and clear blocks, allocate funds and people, from quite a distance.
It's turtles all the way down. So, let's think about executive sponsors here. Why do they change scope and requirements? Why do the act the way they do?
Yes, there are executives who's career trajectory is defined largely by luck rather then acumen, let alone being knowledgeable or empathic to those in their service, or the stakeholders whom they cater to. But that's not the entire story.
Businesses, whether a small 2 man outfit or billion dollar enterprise, do not operate in a void. Their behaviour is very much driven by changes in their environment. Whether that's the markets they are active in, customers they target, labour markets they tap into, competitors innovating and bringing new products and services to market, and public governance issuing a changing legal frameworks.
Changes in scope and requirements are par for the course. Executive sponsors perceive those as investments and try to make risk-benefit trade off's assessing the information they have at hand. This is where uncertainty seeps into the decision making process. Even with clearly quantified information, it's still hard to predict the future. How will markets evolve? What do customers want? What will the competition do one or two years out?
Strategic thinking and planning is hard because of uncertainty. In a military context, this is a clear given for leadership. Helmuth Von Moltke the Elder (1800-1891) famously said:
> The tactical result of an engagement forms the base for new strategic decisions because victory or defeat in a battle changes the situation to such a degree that no human acumen is able to see beyond the first battle. In this sense one should understand Napoleon's saying: "I have never had a plan of operations." Therefore no plan of operations extends with any certainty beyond the first contact with the main hostile force. [1]
[1] https://en.wikiquote.org/wiki/Helmuth_von_Moltke_the_Elder
> we need better management training in general for anyone whose job is dependent on software
For sure, leadership training is an established need. And it's also a thing that is catered to. There are entire libraries, fields of study, management courses and so on dedicated to leadership training. There's no lack of options out there. That's not the issue.
More interestingly, you have to first question how executives ended up in a leadership position in the first place. For instance, many leaders don't necessarily became leaders because of innate qualities that show a due sense of what is understood as "being a natural leader", but because they were born into a context that handed them the opportunities that put them on that trajectory. Do note how I say "many". The above isn't a catch all either. How individuals end up in a leadership or management role is really a matter of many complex factors and happen stance.
And so, having a social studies background, I always tend to be a bit weary when I see the "we need..." argument because (a) the "we" is never specified, (b) the "we need" negates complex contextual factors and (c) it reduces the argument into a single problem that can be resolved in general terms with a single pragmatic solution.
And so that brings me to this point:
> usually lack of understanding and empathy for how software development works
I feel this goes both ways. Trying to understand the reasoning or the why behind shifting business strategies, and realizing that these are driven by fallible human beings who make mistakes based on incomplete information goes a long way. Working towards improving software development practices is a a great goal, but good will never be...
I feel like the process for building your software is more important than the software itself. I.e. How can you worry about building cars when the factory that produces them is burning down, or experiencing a work stoppage because no one ever thought to develop a maintenance schedule for a particularly tricky piece of equipment?
The more I look at this whole enterprise of software engineering as a virtual factory floor, the easier it gets to draw analogies between developers and project managers regarding how we should manage work.
Use an old technology none of the programmers are interested in and they go find other jobs or not work very hard as they put there efforts into their more interesting side projects..
As an example, projects linked to fulfilling legal requirements normally succeed because the motivation is strong - failure = fine/prison time.
Most projects I've seen failure where senior managnent doesn't want the project anymore but need a way of getting rid of it while saving face. Classic way is to pass the project onto another department...
1. The deliverables were not clearly defined and maintained. How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep.
2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project.
How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system.
Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working. If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.
I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not.
In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt.
After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project.
This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.
> Why do only 58% of companies value project management?
Well, that seems to be taking the research totally out of context in the first paragraph.
And then just rambles on about having great people, and having them really well trained in project management. Wow, who would have thought being good at project management and making people better at project management was the solution to getting better at project management!?
"Is scope creep the problem? No, thats just a symptom of people again, and training. Did I mention I have a book?"
Maybe I'm just cynical here, but there doesn't seem like too much insight here.
This a circular advertisement for a book.
I am guessing it’s more to with how most organize socially for human emotional reasons first and tacitly don’t give a shit about ephemeral nonsense except to play “Society: The Board Game”.
If I can dream, non-tech guys can only mention high-level goals based on data than interface. Instead of the mandate "in one day, reimplement snazzy chart from slick app...", tell "show top 5 contributors" and tech guys can provide an economical solution first and iterate on it later.
This means leading those above too: getting more resources, communicating and managing expectations
The nature of projects is that they're often one-offs or something that the company hasn't done before. So unless you're being very generous with time, scope and quality estimates you're likely to be way off because of optimism bias
I've just gotten off two, multi-year projects, the first crashed and burned due to a mismatch between business process, vendors and the skills in the organization to understand what it does and translate that into requirements. From the development side, we made a lot of stuff. Most of it was junk.
The second project arrived at a point underdone. Unable to replace the existing production solution because of a lack of a burning deck. I'd put this down as a failure as well. Mostly on the strategic leadership side.
In the meta sense these projects weren't that bad. People got money for doing them, and that money was spent in the economy.
Maybe Amazon is onto something with their two pizza teams, and 7 page proposals.
Even for companies where that's the case, treating technology like a cost center is like treating legal as a cost center -- existential company killing risk goes way up if you don't pay for the real deal. And for companies where it isn't, you'll just flat out waste your money. Pay for a Yugo when you need a big rig and you'll get exactly what you paid for, which won't be what you need.
Like how they achieve redundancy, resilience, and fidelity in their software development.
And also, get some managers with half a brain, to understand that changes to the requirements can affect development efforts.
This actually has further impact on other projects because everything is done badly.
https://en.wikipedia.org/wiki/Saturn_V
Then when the project fails everyone blames someone else. If you want the project to succeed tell all those people that they will get their reward at the end of a successful project not before it has even started.
2. PM is not technical and believes the story being told.
3. PM calls for a meeting and asks for status but doesn't go to each people to collect information who is delaying or is he waiting for someone else's input. Flow is cut somewhere.
4. With sprints, too many managers but all sprints are handled by few Dev's, DBAs and testers.
5. Project changed its course into a discovery journey and everybody is too focused on the side track.
All this I have dealt.