I am product manager, more than a project manager, even more so now, in agile times.
As a product manager, I am excellent, if I might say so.
As a project manager, I am soso. Don’t like the overhead involved.
That said: none of the projects I did as a projectmanager were not in time or not in budget, all features delivered, bug free within expectations. OK, there was one exception…
But I am a classic waterfall guy, sorry! I like to analyze and plan properly … and the 20% contingency rule always saved my @ss!
And in the end, I want to decide … and take full responsibility!
Now, I kind of hate (!!!) everything agile. I have never seen an agile project being on time or within budget. There were always features missing.
Lead and responsibility was unclear. Developers had the actual power … and always developed something new, instead of looking for standard components to reuse … developers want to develop, after all.
Usability sucked, albeit many user tests. There was never any documentation. Operations was ignored and failed consequently.
And from a financial POV, ROI went always down then drain…
The difference between program manager and product manager might be a more strategic component in program manager?
Thinking about it, that might be why I was so very unimpressed with Scientific Atlanta (the Motorola competitor for my field).
As a product manager, you need to know about and define strategy, of course. But your focus is on making actual products for actual people.
Program managers might have a more corporate look, focussing on nice Powerpoint presentations??!
Scientific Atlanta had quite a lot of program managers
Product managers design the product functionally, work with the engineering leads to come up with tractable product ideas and plans, and with the user experience folks for the art and interaction designs.
Program managers are more organizational and process-oriented, lateral across multiple teams. They are about organizing workstreams and helping team leads coordinate schedules with their upstream and downstream peers.
Both can be strategic or more tactical, depending on level.
The game industry and other places using a studio model has a role called “Producer” which is like a combination of the two.
Yep - I was a producer at Epic. At first I didn’t know what is was (I came from multimedia development). I mean, I knew my job description, but I had never heared about about a “producer” outside of the movie/TV business!
At Epic I was also responsible for planning and timing … and I still use their project plan template to this day (waterfall, of course) - so this is how I learned project management. It was very complex, and I could barely handle it!
That is why I am so happy, being a product manager: you only focus one one thing, and try to make it the best ever!
Now imagine management heard about agile as a buzzword and insists it’s used to develop a motorized kitchen appliance. Fortunately I was not project managing that because I would have passive aggressively requested the budget to do the production tooling 5 times so we can release, collect user feedback, and iterate. What’s a few million dollars more capital than doing it waterfall between friends?
ETA: Project and program manager titles are used for such a wide range of roles they’re kind of useless without more context. They have incredibly different responsibilities in different industries as well.
With the last project, two agile teams burned more than 20M €, no tangible results. In a project before that, a planned 12 month project took four years. With a substantially reduced feature set at release.
In both cases we had a very high bug count at launch … something that would have been absolutely unacceptable in the 90s!
But the agile team had Playstations, bean bags … and a table football, so it was all very cool at least
Also true.
That is why I always make a list with responsibilities when I start a new job, for all team members … and define a gating process … so nothing remains unclear! Of course, resistance is very high … everybody wants to decide, nobody wants to take responsibility…
Also, I still use the work.doc from Epic that describes those kinds of tasks.
All pickguards removed from three basses and sanded the cavities to be filled with epoxy (pickup selection switch hole, two screw holes for thumb rest and the new cavity for the humbucker, where there were once two precision pickups).
First go with filling the cavities is done. Looks already good (well, for some it doesn’t, I know. I will miss the “jokes” about it :-))
Will make a second thin layer, to prepare for smooth sanding…
this epoxy has glas fibers in it, so it’s a little tedious to fill the holes. But it will be VERY stable, also with vibrations. Like a canoe!
I felt a little woozy after a few minutes. Then I remembered that epoxy is not very healthy and you should always have good ventilation. So I setup my Mi Air Purifier, opened all doors and windows and put on warm clothes (it’s freezing outside)
Kids: don’t try that at home. Always have good ventilation when working with Epoxy, if you don’t have a death wish!
Agile’s fine. It does require disciplined teams though.
I’ve been a PM for over 25 years and worked for the largest IT shop in the world is where I come from. Projects are like basses, you use the right tool for the job. Agile here, waterfall there, both have their place
Neither is better. Both are clown shows if it’s the wrong type for the project.
Maybe you wrote the cause of agile failing often with this sentence!?
As agile teams are self-“organizing”, an unorganized team cannot perform.
The last really good self organized team I worked with was in 1995 … which was great, as I really s#cked as a producer then!!!
After that I worked mainly with divas, and every agile project was a power struggle.
With waterfall, it’s almost impossible to fail, as the ProjM and the ProdM are in close control. There is no power struggle, as responsibility and decision making is clear. It’s the ProdM … as it should be…
Nobody likes to be controlled, but as they say in Germany “Das Leben ist kein Ponyhof”.
I like to analyze everything beforehand, get the right (motivated/good) people, plan … and have regular milestones to check.
But I demand that people perform … we are on a quest for the holy grail, always!
If a milestone is not met there will be trouble. Except when we encounter unforeseen circumstances … which can be mimimized in most projects by good analysis.
If you take away autonomy for developers, they can focus on what they should be doing: developing!
I would say with waterfall on a software development project it’s near impossible to succeed. You take the requirements months in advance and by the time you get to coding, your competitor has done something and you have to respond and change your plans, hence agile.
The problem with waterfall for software projects is the lag from when the requirements are taken and when the product is complete. The world is not static and requirements will change.
Agile does not work well with self organized teams I will agree. You need to keep in front of them and keep there eyes on the ball. You meet with them constantly to do work. I spend a lot of my times on these forums listening to teams work just in case I need to step in.
Very true! Now, I have worked mainly in gaming, multimedia, interactive TV/streaming and hospitality.
Those projects were a) always very complex (with many depencecies on other verndors and systems) and b) always had a fixed launch date which was (almost) never less then a year.
So that gives you time to analyze. Also, I enforce using standard software components, be it open source or anything else.
I want to minimize the unknows.
Again, most developers don’t like that, as they always want to reinvent the wheel using alien/voodoo technology.
To me only one thing counts: is this the best product for the customer … not for the developer.
And, let’s face it: most software projects are not exactly rocket science and not as revolutionairy as we tell everybody.
I always have a complete vision of what a product should look like.
Often I write a litlle demo myself, just for fun.
Seldom, UI/UX tests prove me wrong.
And there is one thing I want to avoid: feature creep.
I’d rather launch with a perfect basic product (which should be the best of course :-)), and then add/remove features later.
I hate scope creep myself, however if your competitor implements a neat new feature in their product, you need to update yours before launch. You have to be as good or better than your competitor. Its an arms race.
Which is why I am back in healthcare. We try to make people well and I don’t have a rat race anymore.
I get it!
I worked in the cruise ship industry before. It was very very interesting, really.
But we were large polluters and - of course - it was 1000% commercialized - we made people sick amd hollow, in a way.
And I am a f#cking green liberal, so there’s that!
Maybe I was lucky, as most projects I did were ahead of its time, so there was no real competition?! We did app stores long before Apple, VOD long before Netflix and iTV long before … anybody (except the french).
Albert Heijn, for me, is HOLLAND! They have the best supermarkets in existence.
Every time I cross the border to Holland, I have only two thoughts: where can I get Dutch fast food (frietje oorlog, frikandel speciaal, kroketten/ bitter ballen … and Chocomel) ? And where is the next Albert Heijn?
When I wander around in an Albert Heijn, looking at all those Dutch products, listen to people speaking my langugae, flirting with the cashier girl … I am as close to heaven as can be!
