Who works for the biggest idiots? Top this..

[glenn1]

During a meeting today, the following came from the mouth of our CTO, "I don't believe in doing Requirements Traceability Matrix, business requirements constrain our flexibility to design a solution." And no, this was not an April fool's joke.

me and PM: <facepalm>

Edit: Forgot that he described a project plan as "only a backwards looking document."

 

[Ns1]

is this your CTO?

 

[The Boston Dangler]

http://www.atrixnet.com/bs-generator.html

 

[Red Squirrel]

is this your CTO?

Testing code is so 1990's. If it compiles, ship it! Patch it later. :biggrin: Sadly that is exactly how most software works now days.

 

[Pray To Jesus]

ha

 

[Jeff7]

Testing code is so 1990's. If it compiles, ship it! Patch it later. :biggrin: Sadly that is exactly how most software works now days.

Bugfix: Autoupdate feature attempts to connect to wrong IP address.




:|

Well....pissnuggets.

 

[Matthiasa]

I do believe that that correct response would have been asking for whatever he was on.

 

[Red Squirrel]

Bugfix: Autoupdate feature attempts to connect to wrong IP address.




:|

Well....pissnuggets.

What do you mean it's trying to connect to 10.5.5.5, that's our internal server! :biggrin:

 

[slag]

I have to agree with his project plan assessment. Everyone seems to do the work, then fill out the project plans afterwards. PMO groups are huge wastes of time and resources.

Why do I have to fill out a business assessment, a business proposal, a project management plan, go speak before the group of people who have no idea what this tool is who are not the audience who will be using it and win their approval, then still have to find 2 other similar tools that I know I won't choose because I already found the tool I really want to use, then bring all 3 in house for technical discussions. It's all a huge waste of time and resources and, since I'm a technical person, shouldn't our PMO group be doing the paperwork while I focus on the technical aspects of it anyway?

 

[Markbnj]

I have to agree with his project plan assessment. Everyone seems to do the work, then fill out the project plans afterwards. PMO groups are huge wastes of time and resources.

Why do I have to fill out a business assessment, a business proposal, a project management plan, go speak before the group of people who have no idea what this tool is who are not the audience who will be using it and win their approval, then still have to find 2 other similar tools that I know I won't choose because I already found the tool I really want to use, then bring all 3 in house for technical discussions. It's all a huge waste of time and resources and, since I'm a technical person, shouldn't our PMO group be doing the paperwork while I focus on the technical aspects of it anyway?

Glad I'm not the only one who feels this way. Business people can't commit to requirements, and they're just going to change them as soon as they actually use the feature, or show it to some stakeholder group that missed the first five meetings, so trying to make up for that irresoluteness with methodology and documentation just means you end up chasing your tail. Get the big picture then iterate toward a solution. It's the only thing I've found that works repeatably.

 

[mmntech]

I understood everything up until "requirements traceability matrix." What the hell does that even mean?

 

[clamum]

Testing code is so 1990's. If it compiles, ship it! Patch it later. :biggrin: Sadly that is exactly how most software works now days.

That's how most software works these days? Do you have proof for that (professional experience on open source or commercial products) and can you elaborate? I'm guessing the answer to that is a big "fuck no" and you're clueless.

 

[Red Squirrel]

Buy any piece of software, or even a gaming console, or anything that just came out. The first thing it wants to do before you even use it is patch. If they actually would test stuff before release it would not need so many patches so early.

 

[Matthiasa]

Doesn't work that way. There are often orders of magnitude more end users then people creating a given piece of software. Simple volume dictates things with happen that never showed up in testing. There is no way to test ever possible act of stupidity end users will end up doing. Those that use as intended simple don't run into most of what gets patched.

 

[MagnusTheBrewer]

The biggest problem I see is both the contracting company and the development /programming folks getting too technical too fast. Everyone has to understand the big picture before diving in. That's what the project plans are supposed to be used for. Programmers love to solve identifiable problems, even if the solution to a given problem isn't what's being asked. Then they complain the problem wasn't explained clearly. It may not have been but, too often assumptions were made because of not understanding the broader picture.

 

[Triumph]

I understood everything up until "requirements traceability matrix." What the hell does that even mean?

It's a stupid fancy word for a checklist. You write down the requirements, then someone goes through and actually makes sure that they're met, and puts a check in that box. Simplified.

 

[sdifox]

During a meeting today, the following came from the mouth of our CTO, "I don't believe in doing Requirements Traceability Matrix, business requirements constrain our flexibility to design a solution." And no, this was not an April fool's joke.

me and PM: <facepalm>

Edit: Forgot that he described a project plan as "only a backwards looking document."

Translation: You guys are still going to build a working product, I just don't want to pay for all that shit.

 

[pauldun170]

During a meeting today, the following came from the mouth of our CTO, "I don't believe in doing Requirements Traceability Matrix, business requirements constrain our flexibility to design a solution." And no, this was not an April fool's joke.

me and PM: <facepalm>

Edit: Forgot that he described a project plan as "only a backwards looking document."

What the hell kind of company do your work for?
How old is this CTO?
What kind of project is this?

this is like passing the National Inquirer on the shopping isle.
I need all the juicy tidbits of this stupidity.

 

[IndyColtsFan]

I have to agree with his project plan assessment. Everyone seems to do the work, then fill out the project plans afterwards. PMO groups are huge wastes of time and resources.

Why do I have to fill out a business assessment, a business proposal, a project management plan, go speak before the group of people who have no idea what this tool is who are not the audience who will be using it and win their approval, then still have to find 2 other similar tools that I know I won't choose because I already found the tool I really want to use, then bring all 3 in house for technical discussions. It's all a huge waste of time and resources and, since I'm a technical person, shouldn't our PMO group be doing the paperwork while I focus on the technical aspects of it anyway?

I'm not a big fan of PMs or PMOs -- in my entire career, I can count on 2 fingers the PMs I've come across who have been worth a crap. And this is coming from someone who often considers moving into that role. The ones who are really good generally have extensive technical backgrounds and can speak the language rather than throw out PM buzzwords like "requirements traceability matrix," "channels of communication," "update your artifacts library," "let's analyze the WBS," etc.

Anyway, you're doing it wrong. I'm sure I'll catch flack from some folks here on AT for saying this, but at my job, PMs serve me, not the opposite. I tell the PM what needs to be done, what resources I need, and tell him/her to make it happen.

Paperwork like you mention above isn't the job of the technical resource -- the PM can work with the business to get it done or it won't get done IMO. The only exception would be the project plan -- as the technical person, you probably would need to have significant input on project milestones, individual steps in the plan, etc. Would you really want a professional paper-pusher with no technical skills doing this by himself?

 

[Ichinisan]

Buy any piece of software, or even a gaming console, or anything that just came out. The first thing it wants to do before you even use it is patch. If they actually would test stuff before release it would not need so many patches so early.

I'm still downloading the patch for Super Mario Bros. 3

 

[somethingsketchy]

Try having a Project Manager not actually manage projects. During one of our last major software releases, he "insisted" everyone else should manage the project, not him. I'd swear he was the laziest manager I've worked with.

 

[BikeJunkie]

It amazes me how resistant most non-technical people are to anything related to formal requirements tracking (and this includes many CTO's). They either

1) Hate documentation in general and just want to fly by the seat of their pants. In other words, they have no fucking idea how to do their job.

2) Hate having documentation that could hold them accountable later on. Sucks when you can't blame IT/IS when a client kicks in your door because your product/solution doesn't do XYZ.

Usually it's some combination of both, though. I worked for a VP for a long time who mostly fit with #1, and it drove me insane. I have no idea how he got to that level, but he had zero knowledge of SLDC management, Project Management, or anything that resembled a professional approach to modern software development. I tried time and time again to bring him up to speed, but he would immediately go into "deer in the headlights" mode. He was fired a year and a half ago, about a month after I quit.

That's what happens when you make an AS/400 guy a VP and said guy decides his learning period has ended.

Right now I have a client who's very resistant to formal requirements documentation, and that has induced all the standard pitfalls. When I was first brought in, I tried to use a formal approach but was told "that's now really how we do it here." So I did it their way for about 6 months. As time when on, I would be asked more and more "I can't remember - what did we decide this was supposed to do?"

I came up with a sneaky-ish solution: my team doesn't create anything until an email is distributed to the stakeholders outlining the requirements, and said stakeholders reply with "do it."

So it's not a word document :shrug:

I'll get them there...

I worked for a heavily matrixed organization and it was awesome. Everyone was accountable for everything they said, did, and agreed to. No more, no less. Nowhere to hide if you fucked up, regardless if you were a developer, technical lead, BA, PM, QA, etc.

Everything was awesome :whiste:

 

[BikeJunkie]

Try having a Project Manager not actually manage projects. During one of our last major software releases, he "insisted" everyone else should manage the project, not him. I'd swear he was the laziest manager I've worked with.

Welcome to all project managers who were never engineers.

 

[BikeJunkie]

Anyway, you're doing it wrong. I'm sure I'll catch flack from some folks here on AT for saying this, but at my job, PMs serve me, not the opposite. I tell the PM what needs to be done, what resources I need, and tell him/her to make it happen.

Nailed it. Let's face it: a PM doesn't have the power to actually make the rubber hit the road, and that's okay. Used properly, that's not what they're for. Their job to remove obstacles and raise their hand when something looks wrong.

 

[CPA]

Glad I'm not the only one who feels this way. Business people can't commit to requirements, and they're just going to change them as soon as they actually use the feature, or show it to some stakeholder group that missed the first five meetings, so trying to make up for that irresoluteness with methodology and documentation just means you end up chasing your tail. Get the big picture then iterate toward a solution. It's the only thing I've found that works repeatably.

Yeah, it's all the business person's fault. It has nothing to do with IT not understanding the requirements, even though they're shaking their heads throughout the initial requirements assessment, right?