Occasionally my brain starts a thought that just keeps going.
Like it did when I started jotting down some ideas around project management for software projects.
Each of these thoughts are key considerations in each and every IT project.
So here they are in no particular order of importance.
See if I've left any out. I'd be delighted to hear from you in the comments section.
It all starts with the realization that there is a problem to be solved. If there is no problem that can be articulated, then there is no real need to apply technology.
You have to go beyond defining that a problem exists. You must also be able to define the benefit of fixing the problem.
Does this work really need to be done? What other items are competing for resources and budgets. Be ready to provide the answer.
How would fixing the problem assist the organization to achieve its core business or purpose? Does this project align with the ‘big picture’?
Is there more than one solution? Perhaps there is a simpler solution than technology (e.g. a process change).
What are the potential benefits that may be derived from implementing this solution? (Other than the obvious) (e.g. making data available to other divisions/ departments)
You can’t really use productivity as a reason for implementation of technology, since there is a tremendous amount of data proving the contrary. You must be able to define realistic cost savings or increased potential for income.
Does the project have executive sponsorship? If not, success is unlikely. Who are the stakeholders in the success of the project?
There will always be the nay-sayers who resist change. You must have a clear message as to what the need is to do the project
Who needs to be lobbied? Just because a project is logical and has great value for the company doesn’t mean you will get buy in. Politics is a very real risk to any project. Ensure you are not pushing this project for personal political gain. If so, there will be those waiting in the wings to ensure your failure.
“Great things can be accomplished, as long as it doesn't matter who gets the credit.” (Ralph Waldo Emerson)
Involve the stakeholders early in the process. Get their needs and preferences defined. What do they need out of the system? The system won’t be used if it doesn't add value to the users in the trenches.
Not everyone will buy in to a project just because it adds to the organization bottom line. Each participant must have a personal benefit if the project is completed.
If possible, disarm those who would seek to scuttle the project. If the benefits are well defined in light of corporate objective, then most opponents can be convinced that the project is not being done for the political gain of an individual or department.
Under Promise and Over Deliver. Most expectations are mismanaged based on over promising the benefits and capabilities of technology.
Projects have both direct and indirect costs such as hardware upgrades, software licenses, travel, training, etc. Many custom developed applications have an ongoing maintenance fee of 10-15% yearly. Specialized hardware purchased for the project will likely need to be upgraded every few years. Ensure these are accounted for in determining the cost of the project.
Play by the rules… Document, document, document. Have a clear statement of work that outlines deliverables, expectations, time frames, etc. Don’t hold meetings without agendas. Keep a paper trail of all decisions. Don’t change the scope without a change order.
What are the risks associated with doing the project? Avoid being blind-sided by events that could have been prevented early in the project. Most risks, once identified should be prioritized as to their potential impact. Most risks can be mitigated with planning early in the process.
Is this project dependent on any outside factors? (i.e. Budgets, other projects, personnel, etc.)
Are there permissions (both internally and externally) that need to be secured before the project proceeds? (e.g. permits)
What skills are needed to complete the project? Do you have the skills in house, or will you need to hire additional people or an outside firm?
Once you get into the thick of things, be ready to take on the role of coach, taskmaster, etc. to keep the project on track. Things will spin out of control quite naturally if the project is not continually managed.
Managing projects is a fine balance of Time, Resources and $$. Set realistic time frames for delivery that takes these factors into account. It is extremely difficult to recover the goodwill lost when a delivery date is missed.
This has to be a team effort! Share the pain, share the gain, and share the glory.
Policies & Procedures
Formalize responsibilities and develop group policies (but don't get bureaucratic!). This goes a long way in mitigating personal conflicts.
If you are developing software, the presentation of the interface is key to how effective the application will be to use. If the interface is not intuitive, and does not follow accepted practices, then the potential for introducing errors increases substantially.
A picture is worth a thousand words. Use screen prototypes to convey functionality before the application is built. This is an essential part in managing expectations.
Work to a defined project management process. Adapt it to suit the scope and scale of the project, but ensure the stages are well defined, with clear exit points for each stage, so that everyone knows what to expect next.
Never jump into a full scale project without testing the waters first. Prove the concept with a pilot project.
Use the vernacular of the organization. Ensure that users know what they are getting, what will be fixed, replaced, etc.
End Users are NOT the Beta test team. Make sure the application works before it is released to the end users. If users do not trust the application, they will not trust the accuracy of the data, and find alternate ways to manage the information.
Leverage the success of your project by telling others. Use blogs, tweets, press releases etc. to provide the institution with some positive PR. Where practical, be willing to share with your peers.