I'm curious about what a generic checklist would do for you, Danni. Doesn't your project have specific objectives, deliverables, and success criteria associated with it?
But to expand the topic a bit, and with the assumption that you are talking about an "IT project," isn't roll-up, ramp-up, user training, process confirmation, etc., actually part of the real project? IMHO, too many IT projects are defined too narrowly -- the real project needs to include not only the IT effort, but the additional aspects (like those mentioned above -- which might serve as a "mini-checklist" for you) that actually drive real benefit for the organization. A well implemented IT support system is meaningless/useless without the roll-out and acceptance by the users. The real project needs to define, support, and get to the real purpose.
There are two kinds of comments on these discussions I find annoying -- the "but we're different" answers (way too common in the PM world) and the "it depends" (way too common in the world in general) answers -- especially those that don't clarify or justify their existence.
On what does it depend, niraj? What kind of IT projects are worth doing without having some impact on users or processes? (The only possibility that comes to me are bug-fixes, but they're really only completions of unfinished past efforts.)
Frank I do agree with you. Within a company there should not be a project that does not have some impact on users or processes? That is the responsibility of management at what ever level that operates in you organization.
However I do have an ?it depends?. In consulting we sometimes deliver projects that despite our best attempts do not appear to be set up for success for the client. We can deliver what they ask for and contract, not what they need. I have unfortunately worked projects that were IT driven, not business driven. We delivered what the asked for. When the client tried to implement to the business, the business said, that?s nice but it only handles 30% of what we do. This client was a reference for us on future bids.
From a consultants perspective you make sure everyone understands through out the project that this is what was asked for and it was delivered. This affects the deliverable list.
As a consultant if the client asks for apples to make orange juice despite your assurances they need oranges, you give them apples. When you are done you may ask them how it tastes. Not to say ?I told you so?, that will be understood, but to position yourself and the client to work together on the next initiative too make them truly successful within their own organization. After all that is the goal of a good consultant.
Hopefully the above only needs to happen once.
I think this would imply internally as well. A good PM will try to drive the sponsor to success. A good PM will say this won?t work if it truly won?t work. Unfortunately sometimes you are just asked to deliver. Saving Changes...
I agree Frank. And perhaps this belongs in another thread.
Sometimes the PM has to live with the call of the executive be it internal or external. A third party can make things more complex.
It does raise the question of where do your stakeholders end? If IT is your contact and you do not have access to the business. Turning down the work is an option. But if IT has it's mind set, then they will get someone to do the work.
In my mind perhaps a separate issue of account management versus project management. Saving Changes...
I agree with Frank in general terms. Staying away from projects that won't actually accomplish anything is a good idea.
However, some PMs find themselves facing working on the project or looking for a new job.
If a PM decides to take on the project of this nature I can understand that. What I am apposed to is the conclusion that because I'm executing a bad project processes for good projects should be changed to not expose these bad projects.
If the process I'm using does not keep me from executing bad projects it's a bad process.
So in general if you decide to execute a project that your process says you should kill, then don't say the process needs to be changed. Admit your doing something that probably won't have great results. Saving Changes...
