I'm several layers/levels above the people involved in the project I'm about to describe.
The general requirement is for a web based issue management system. The system is a small part of a much larger project.
The lead pm has a tech pm who is supposed to handle this portion of the project. The lead pm asked me if it's normal for the help information to not be in the context of where the help was requested. The lead pm was providing feedback about the site and wanted modal dialogs and such for error messages and wanted me to take a look. I'm looking at the system and I'm thinking...
- a new app was developed in cold fusion!?!?
- the app has extremely poor data validation
- the app data validation page navigates away from the data entry form
- the app help page navigates away from the form
- the db schema was not discussed between the developer and the pm
- the db schema was not discussed because it does not exist
- there is a menu page - i.e. once you go to a page, you have to go back to main menu and then go to the next page you want
- the lead pm does not know what the dbms is...
- there is a tech pm and she does not know what a dbms is...
- the lead pm has wanted to fire the tech pm for a long time, but the tech pm is protected...
- the lead pm suggested that the exact functionality desired exists in several proprietary projects (several of which are open source - bugtracker, bugzilla, etc.), but the tech pm and dev wouldn't listen.
I have two questions?
Do I
- fire the dev?
- fire the tech pm and the person protecting her?
- fire the lead pm?
- download and configure bugtracker/bugzilla for them and then fire all of them?
- download and configure bugtracker/bugzilla for them and then go have a beer to forget my sorrows?
and isn't it SOP for the db schema to be discussed and rigorously thought through very early in the project?
EDIT:
I used to work with a wide variety of clients with disparate levels of technical knowledge (and intelligence). I always discussed the db schema with the stakeholder. If they didn't know what a schema was, I would teach them. If they didn't have the background to understand, I would still discuss the schema with them - even if they didn't realize we were talking about the schema. In most of the projects I've been directly involved in, the data is the most important part of the system. Thoroughly hashing out the schema/domain model has been critical in getting to a good understanding of the system and what things can be done and reported on. I have high regard for the opinions of the posters on SO. It's interesting to note that my approach is not the usual course.
BTW - the sad thing is that the project uses tax payer funds and the IT portion is a collaboration with a prestigious university... the dev and tech pm are long time employees - they are not inexperienced. I find it especially sad when I know intelligent and hard-working people who are jobless and people like these are employed.
When I was younger, I would report this type of ineptitude up the chain and expect appropriate action. Now that I'm up the chain, I find myself not wanting to micro-manage other people's responsibilities.
My resolution was to have two beers and get back to my responsibilities...