No one can manage projects, especially technology projects
forbes.com
forbes.com
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 become perfect. And trying too hard to reach perfection might even backfire.
A lack of understanding and empathy of how software development works could be forgiven. A lack of understanding and empathy of how human beings feel and think - whether it's developers, project managers or executives - can't. It's the latter which makes all the difference at the end of the day.
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.
"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.
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...
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.
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.
> 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 actually has further impact on other projects because everything is done badly.
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.
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
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”.
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.
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.
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.
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...
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.
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.
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.