You’ve been managing large software projects and you’ve never had to delay going live, ever?
Wow, that’s got to be the best track record of any PM on the planet, literally.
Statements like that keep hurting your credibility. I doubt you could find any other person that has managed large software projects and never delayed, it’s so unlikely it borders on impossible.
No, you honestly don’t and I can’t figure out if you are just being argumentative or if you honestly work in a world where 30% success is not called a failure.
It’s a bizarre position to take and I doubt you could find even a handfull of people in the industry that would agree with you.
“Minor milestones”? Do you believe the stuff you post?
Going live with the system is the primary and most major of all milestones from the start.
THAT’s the goal is to begin using the system (and implied in “using” is successfully).
You’re serious that you really have managed software projects but you consider turning on the system to be a “minor milestone”?
It’s a very good question and is probably part of the reason for many failures, but John is right that it doesn’t let anyone off the hook, it just means it’s not easy to do.
OK, then the next question must be: if actually gosh-all-bona fido experts don’t agree on such a question, how does someone who doesn’t know shit from Shinola about the science involved decide who has got the Right Stuff, and who doesn’t?
Raft, it’s tough avoiding responding in kind to you. You haven’t offered a single fact here. It’s all your opinion. Do you have any evidence that there was even a milestone to achieve here? Maybe your company evaluates their work on the basis of anonymous opinions and popular media reports, but you aren’t showing me anything that says what was supposed to be achieved with the ACA website or when. Is this how you manage? Do you listen to rumors about problems and make declarations of success or failure? Do you actually manage or are you just a bean counter? Do you have any technical ability? And I’ll tell you the same thing I tell customers who are amazed when they are delivered bug free software, “I didn’t put any bugs in because you didn’t ask for any in the contract.”
Now if you are having trouble getting your projects done on time without problems I’d be happy to help you out. I’d also advise you to concentrate more on solving problems instead of criticizing the work of others. Now I’m sure you have little control over these things. You probably have little or no say at the time when a project is established, and have no choice but to accept requests for additional functionality or unreasonable timelines, and I’m sympathetic to that because I had the luxury of avoiding those situations, something I did intentionally. But you really need to gain some perspective.
I addressed that in my previous post:
1 - experts in the type of system being built (expert=has successfully created similar systems) won’t differ in their opinions by the range you mentioned, their estimates will be substantially similar. If the system is so unique it’s outside the realm of any expert then you don’t manage it like you know, you take a different approach because you simply don’t know.
2 - When looking for experts you need to find someone with a successful track record in similar types and sizes of systems.
And there will be no occasion, can’t happen, that I will have more than one opinion on that? And if I am offered more than one opinion, and the two (or more!) candidates for my trust both have the credentials you suggest, then what?
How would you explain to a non-technical person why you are right, and the other guy is wrong? No snark intend or implied, but it seems you guys are having a hard enough time explaining it to each other.
Sure I have. It’s a fact that the industry (evidenced by industry publications) view a system that is not functional for the majority of it’s transactions after 3 weeks is called a failure.
You’re the one offering a counter “opinion” but not supporting it with any evidence. Are you able to find anyone in the industry that agrees with you? Who are they? What are their credentials?
Ok, this is getting funny now.
There is substantial evidence they intended to and did in fact turn on the system on October 1. Do you dispute that also?
And there is substantial evidence that they intended to have the system capable of completing the majority of transactions. I’m sure you will question that, I anxiously await your comedic reply.
In other words you don’t have any facts to offer. You could easily get me to offer an opinion, which I haven’t done so far, if you presented some actual information. I’ve only pointed out that you are offering a baseless opinion. Show me the requirement to have the ACA website running and completing the majority of it’s transactions after 3 weeks. Also I’ve been busy, maybe I lost track, but how many weeks since the start of this rollout?
I would love to sit in on one of TriPolar’s projects:
Team: this project plan seems to be missing the actual go live date, do we just not have that page?
TriPolar: I don’t consider that a milestone. It’s more of a kind of thing I just try to kind of keep in mind, maybe as we get close we might discuss it at the water cooler, or crack a joke about it in a status meeting, but I rarely even put that in the project plan. I mean, really time is just flux in the quantum structure of the universe and whether we wrap this up next week or in 10 years really isn’t so important but we should probably be trying to continuously improve as we go.
You know, guys, it could be that both of you know what you are talking about, and neither of you is an idjit.
Remember when they rolled out that Part D plan for Medicare? IIRC, that didn’t win any Nobel prizes for interface excellence. Was the computer geek community in complete and utter unanimity on that, everybody knew exactly what was wrong, and how to fix it? The people who designed it, did they all have .AOL on the end of their e-mail addy?
I suggest, with all becoming modesty, is that if there is firm disagreement among people who’s claim to expertise is valid and verifiable, then there is another factor that has not been brought to light.
My guess (and a guess it is! let me be clear on that…) is that the original design anticipated that more states would do state exchanges, which would be smaller and hence, more reliable. They did not anticipate the extent of hysterical resistance, therefore did not realize the scale they would be dealing with.
(I managed a course in BASIC, and my mind spattered against assembly language like jello fired from a cannon at a mountain. I claim no expertise whatsoever. Just to be clear, so I don’t have to defend credentials I ain’t got.)
The only thing we are really disagreeing on at this point is whether a software project launch that can’t complete the majority of it’s transactions for 3 weeks is called a failure or not.
There is not a single person I know that wouldn’t call it a failure. My peers at our vendor’s or other companies have called it the same thing when the topic comes up.
I doubt you could find very many people with experience that agree with TriPolar on that.
I think the only thing that is clear from the outside is that someone made a decision to go live when the system wasn’t ready, which is a project management failure.
Yes, it is obviously mostly that. There is more, but I’ll save it. Raft is simply trying to salvage some dignity after calling something a failure before it’s over, based on his own made up goals. His utter failure to provide facts demonstrates that.
Just because 2 people disagree doesn’t mean the answer is somewhere in the middle, sometimes a person is just wrong for whatever reason.
Go privately ask people that you know and trust that do this for a living, maybe people on this board, whether the people in the industry would normally call this a failed launch. I don’t need to know the responses you get.
Or go look at all of those industry publications I listed earlier that all have articles talking about the failure of this launch.
Nope. I’ve been pretty clear that we are talking about the launch of the system and I would say generously that anything less than 50% success on transactions is a failure.
Ignoring that , I’m curious about your statement that you’ve never had to delay a project in your 40 years of experience.
Do you really stand by that statement? Because the people that I know that are exceptional at managing large software projects (much better than me), the best in their field, can’t even claim that.
That statement flies in the face of reality and hurts your credibility.
You know, I’ve typically enjoyed your posts over the years, but that statement is simply ridiculous, why did you post that? Was it out of frustration?
I’ll be more specific so you understand my claim. The projects taken on by my own company were always on time and on budget. I had to delay projects as an employee or consultant when I had to take over something already started and things were not going well. I’ve also had to delay programming projects for various reasons, sometimes my own fault, but not in the capacity of a project manager, I was simply a programmer in those cases, and usually I had foolishly accepted someone elses deadline to get the work. It’s the reason I wanted to avoid that kind of thing. As a project manager in my own company I would not start unless I had an iron-clad contract where I knew the results could be achieved. A couple of times I had to take a loss and back out of contracts when I was dependent on unreliable clients. You probably don’t have that luxury at your job, I said before I was sympathetic to those circumstances.
In a purely commercial project, that would probably be true. But in this one, the go-live date had very little flexibility, essentially none. The development had to be paced by that date, the date could not be paced by the development status. The failure was in planning and execution to meet a rigid constraint - so perhaps the failure of project management was in misunderstanding the constraints and requirements, inappropriately applying a commercial mindset in the expectation that the ACA rollout would simply have to fucking wait until they got good and ready?
Agreed, there are alternative approaches that could have been taken.
But looking at what they did, what does turning on a system that doesn’t work actually accomplish? That action increases costs, increases the time to get it fixed (due to wasted resources) and people still can’t use the system, not sure why that would be preferable to delaying it.