While there are different styles of managing IT projects, including IdM projects, there are a few good habits you should adopt for your project.
For years, I had a great deal of success following the suggestions of Steve McConnell in Rapid Development: Taming Wild Software Schedules. Now I am not on the publisher’s payroll or shill for the book, but I found it a excellent analysis of why projects in IT go awry and become run away trains (more likely, run away train wrecks).
Note that this is not extreme rapid development, which is a whole dogma and ideology in its own (and not really applicable to IdM projects, in my opinion).
But here are a few suggestions of what to do with the development effort:
- Change Management in Place – agree to nothing and touch nothing until a change process is in place. IdM projects by their nature drift and change scope almost hourly (on call now where compliance, both HIPPA and SOX, are changing the scope of a project. A procedure to evaluate changes that everyone agrees on, approved before you start.
- Daily Build – Keep on instance in Staging that represents the currently most advanced build of software. All developers should check in their code changes each day by 4 PM and it is compiled/deployed and tested by the project lead. Nobody goes home until the site runs as expected. Keeps coders from going off on a tangent for a week and then have integration issues. The bite off smaller changes that can be corrected before the get out of hand.
- Status Reports – Killer for a project, particularly at crunch time with the deadline looming. Everyone wants to know the status and how close are we. The daily builds are one way to help. Point inquiring eyes to the staging site and ask for questions. Team leads – fly air cover for your developers and keep them out of status meetings. Prefer set status meetings every two to three weeks versus weekly – weekly makes status meeting a significant consumer of resources.
- Project Collaboration Site – Think emails and shared network drives are enough to share information? Wrong. Too many moving parts. Use a collaboration site to track project artifacts (read, the latest version of project documents). People looking at different versions of project documentation are technically useless.
- Code Change Control – Take the time up front to build your CVS versioning site. Publish the procedure on it is to be used and how code gets into production. On one project recently where “Steve” was responsibile for production code. Did anyone not know that Steve was an outside contractor with an expiring contract and also prone to be hit by a bus?
- Lower the scope of the project – Start small and iterate phases. Management may have grand schemes, but IdM projects are a journey, not a scheduled trip. Needs, priorities, and focus change, so have discrete deliveries that build on each other. Recalibrate after each drop.
- Acceptance Criteria Known Up Front – How does everyone know we are done if nobody knows what will signify victory. Never start a project that does not have a know “ta-dah” at the end of it. Plus, this keeps everyone’s eye on the ball as they are developing. They know what hoops they have to jump through to complete the project.
- Hire into needs, not when needed – These are fast moving projects with only a 3-6 month window usually. To try and get “a new guy” on board once the project ship sailing will insure the project has qualified skills ready to go. Throwing addition bodies at a project now adds the heavy load of hiring, training, and integrating into the project. Rather have a highly skilled developer being bored (my fault as project leader) than realize we have to hire a skill set 4 weeks from go live.
Hopefully you know these. Never hurts to go through them again.
Leave a Reply