Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
My company has spent millions on these people when what we really needed were more people to actually DO things, not have more people looking over the shoulders of those who do.
Exactly. Theres too many armchair quarterbacks in most places now that do nothing but sit on their computers, headsets, spreading their opinions around and very littler "doers" How many pointless layers upon layers of management does a place need? Thats like having an army full of nothing but officers and no enlisted.
Ive been in your shoes and Im willing to bet very little if anything actually improved with the countless layers of middle, upper, project management etc.
I work in IT, and I'm on several large, concurrent projects where we have PMs.
Each one of them, down to a person, acts like they're the boss of the analysts and engineers actually doing the work. I received a request from one of them this morning to create user accounts. My team doesn't handle that, and I was never informed of what type of accounts they needed. I get a nastygram back that "I'll take this to someone else if I need to," CCing other employees on my team who are no longer on the project. After all that, the vendor PM still didn't provide all the information required to create the accounts.
I was placed on a new project last week with a brand new PM who has never done this type of work before. He's a nice guy, but clearly in over his head and has no IT background. He's useless.
I have another project where the PM has been out sick for weeks/months and follows up on every single minor issue. She wants to another the status of minor support cases and other super granular data. She's not around enough to help, and being so granular is causing us to lose focus on the bigger picture.
Anyone else find these people to be damn near useless?
People who supervise IT people with no IT experience are dangerous. They establish deadlines with no thought as to how much coding is involved. Have any of you been asked how long do you think that this will take ten minutes after they present you with a project? Proper requirement analysis takes a couple of hours even it it is a single program being written.
People who supervise IT people with no IT experience are dangerous. They establish deadlines with no thought as to how much coding is involved. Have any of you been asked how long do you think that this will take ten minutes after they present you with a project? Proper requirement analysis takes a couple of hours even it it is a single program being written.
That's not how that works. I don't supervise IT people. I manage the project. We are Agile. We do story sizing where THE DEVELOPERS THEMSELVES tell us how long they believe a story will take. Essentially, they set their own schedule and timeline. Stories are also groomed with the developers and product owners. There is room to adjust and move stories to later sprints, etc.
It's amazing how folks still can't understand that there is more to a project than the tech.
If you talk to experienced engineers, one of the first things they tell you they HATE is when a project runs late, the senior management's invariable response is "let's have daily emergency status meetings that take three hours out of the heart of the work day, until the schedule delay is made up".
LOL! So true. I was about to write a post that says this -- but you did it first. I'm so glad I'm retired now.
Quote:
Originally Posted by turf3
If your organization has technical people doing project management (and it will usually be the most experienced people, the ones who REALLY need to put their heads down and concentrate on the problem), their constant attendance at status meetings will only slow down the work even further. The solution is to hand off all that management-managing work to the PM, so the technical people can concentrate on solving the problem.
Very true.
I remember everyone working around the clock leading up to tape-out for a next gen processor, and it seemed like everyone up to & including Andy Grove, Craig Barrett (& once even Gordon Moore) calling every 15 minutes wanting a status update...
I'm so glad I'm retired now. Working for a living is highly over-rated.
People who supervise IT people with no IT experience are dangerous. They establish deadlines with no thought as to how much coding is involved. Have any of you been asked how long do you think that this will take ten minutes after they present you with a project? Proper requirement analysis takes a couple of hours even it it is a single program being written.
Exactly what I had to deal with when I was a software developer.
Exactly what I had to deal with when I was a software developer.
And then there are the user requested design changes as you get close to code completion. And they still expect the deadlines to be adhered to. You make the coding changes which may include scraping or rewriting entire routines and then you need to modify the test plan to accommodate the new changes. What really happens is that unit and system testing gets abbreviated.
That's not how that works. I don't supervise IT people. I manage the project. We are Agile. We do story sizing where THE DEVELOPERS THEMSELVES tell us how long they believe a story will take. Essentially, they set their own schedule and timeline. Stories are also groomed with the developers and product owners. There is room to adjust and move stories to later sprints, etc.
It's amazing how folks still can't understand that there is more to a project than the tech.
Please define story. It's been a while, but for me the average IT project went like this.
1. Business problem recognized and defined.
2. Initial investigation into requirements - how many programs what do they do
3. High level specifications written.
4. Detailed specifications written.
5. Schedule set up for coding, unit testing and system testing
6. Coding
7. Set up test plan after coding because only after coding do you know what you want to look for.
8. Unit testing
9. System testing
10. In mainframe shops, I would strongly recommend Silk Test with parallel execution and expected results comparisons.
11. In UNIX/Linux shops there are utilities right in the operating system that will compare files in detail.
Of course this assumes that a parallel system exists with sufficient data to simulate real world processing.
If anything, the opposite is true. It is much easier to automate coding work than it is to automate the FULL job of a PM. Heck, we already have low code development using platforms like Pega.
I don't see any automation built for handling the people, process, or regulatory work done by PMs.
Code generators create code that is difficult to maintain. It is not common for coders to write a new system. Code updates and modifications are much more common.
Move IP-cust-num to ws-cust-num is much more common than move X32-cust-num-32x to x32-cust-num-32y.
Which one would you want to modify and which is in working storage and which just came off of the screen?
We have had both good and bad. The worst one we had just wanted herself to look good to upper management and served no useful purpose. The one we have now communicates really well and knows every aspect of the business, and cuts through red tape. Not the greatest on creating schedules but smooths things over with management when a planning error is made.
Bad ones make more work, more reporting, and more “accountability“ for the people they are supposed to help. Good ones allow the rest of us to focus on what we do best.
Please define story. It's been a while, but for me the average IT project went like this.
1. Business problem recognized and defined.
2. Initial investigation into requirements - how many programs what do they do
3. High level specifications written.
4. Detailed specifications written.
5. Schedule set up for coding, unit testing and system testing
6. Coding
7. Set up test plan after coding because only after coding do you know what you want to look for.
8. Unit testing
9. System testing
10. In mainframe shops, I would strongly recommend Silk Test with parallel execution and expected results comparisons.
11. In UNIX/Linux shops there are utilities right in the operating system that will compare files in detail.
Of course this assumes that a parallel system exists with sufficient data to simulate real world processing.
You described waterfall project management. Many companies are moving to Agile, which is an iterative methodology.
A story is just a simple piece of the overall coding work. It simplifies the understanding of the task. It's written in the "As a," "I want," "so that" format that can easily be understood by all parties including the end user.
For instance, "As a financial analyst, I want Adobe Acrobat added to the system so that all my reports are available in PDF format."
Please register to post and access all features of our very popular forum. It is free and quick. Over $68,000 in prizes has already been given out to active posters on our forum. Additional giveaways are planned.
Detailed information about all U.S. cities, counties, and zip codes on our site: City-data.com.
Please register to participate in our discussions with 2 million other members - it's free and quick! Some forums can only be seen by registered members. After you create your account, you'll be able to customize options and access all our 15,000 new posts/day with fewer ads.
