• Project Management Lessons

    Feb 06.08 | Technology   

    Over the last 6 months I’ve been leading a pretty substantial data migration project at the school.  We have a group of MS Access-based administrative applications that started out as small side projects 8 years ago.  Over that time they’ve proven useful, and spawned more wide-spread use.  And grown to the point where they are mission critical administrative applications used for budgeting, expense tracking, payroll, employee scheduling, etc.  Data tables running in Access no longer offer us the performance, security and reliability that we need.  We decided to make the leap to converting the data tables to MS SQL server, while still keeping the client interface running in Access.  Yesterday was our go-live day, and through a lot of hard work from a number of people our launch was successful.  Early reports are very positive, with major performance improvements being experiences by our clients.  On the back end we’ve started implementing SQL routines which are giving us the required security, reliability and data integrity.  But the process was not without its mis-steps, and on reflecting back over the project so far I have learned some valuable project management lessons.

    As a small scale database and web developer, I’ve mostly worked as a one-man band.  Sure, I’ve developed my own work routines over time, and they serve me well.  But they’re informal practices, observed as I see fit — and if I violate my own rules I have only myself to blame for the consequences.  Mine is not an unusual situation — I know plenty of other developers in the same situation.  But as the world gets more interconnected, and applications get more complex, the one-person team is hard to preserve.  I found the leap from managing myself, to managing a team of developers to be a pretty big one.  Some thoughts:

    •  Appreciate the full scope of the project — Managing time, tasks and schedules is much more complicated when working with a group.  Three people doesn’t make it three times as complex — more like 9 times.  Its an exponential thing.   Formalizing your working practices will be critical to project success.  Of course you don’t want to be weighted down with too much structure, but having documented practices, regular meetings, formal deadlines, and other standard “project management” elements need to be there.
    • Set standards up front — Agree on standard programming practices, naming conventions, documentation requirements, communication, testing expectations, storage locations, etc. at the beginning of the project.  Again there’s no need to be dogmatic, and you don’t want structure to impede team members work.  But team members need to agree on these things, and then the project manager (you) need to insure that they play along.
    • Set a deadline and stick to it — Everyone works better with a deadline.  And set expectations for what will happen if team members miss deadlines.  In our case we set a final go-live date and told our group if their applications weren’t ready they were being taken off-line and they’d need to deal with their clients directly.  Kind of harsh, but it worked.
    • Help team members find time — Make sure team members understand what time of time commitment will be required AND get buy-in from their supervisors.    My standard joke with most things thrown on my desk is that I’ll get to it “in my spare time.”  Which of course never materializes.  The assumption here is that you’ve got a group with people from various departments, none of whom report directly to you — a very typical situation around this office.  Get a formal time commitment.
    • Provide Training — One of the great success in our project was a SQL class attended by our developers.  The opportunity came up by chance, but it provided needed training and was very well received.   Team members felt more invested in the process, better prepared to meet the challenges, and it gave us a common experience that helped our other work.
    • Watch outside experts carefully — Outside contractors can be a blessing, providing much needed expertise and willing hands.  But don’t assume they  know what they’re doing.  Even if technically proficient they don’t know your organization, and its implicit work rules the way you or your other team members do.  Watch them even more closely than team members, making them adhere to strict deadlines, code review and other oversight.  And if they aren’t performing cut them lose quickly.
    •  Set up an issue tracking system — communication is going to be very important on all sorts of levels.  Talking to yourself is pretty easy (if a little nuts!)  Keeping a team talking can be tougher, especially a group used to working alone.  Don’t overburden things, but get a system in place.  By the time the project is done you’ll already have a good start on project documentation.
    • Establish shared test and development environments — again its easy to do this informally in your own work.  But formalize it for the team.

    This is all standard Project Management 101 type stuff, but it all seems much easier in the classroom.  Its all also implicitly followed by most of us in our own project work.  But in making the leap from single-person to multi-person project teams these are the types of elements that will lead to project success — at least they worked for us.

    Related Posts

    • Author: Randy

    In my day job I serve as Information Technology Director for the Yale School of Drama. Otherwise I garden, play guitar, build stuff out of wood, take photos, play around with technology and have been blogging since 2003.

    Share on: LinkedIn

    Stay Informed!

    Did you enjoy this post? Then subscribe to my email newsletter and have the daily posts delivered directly to your inbox. Enter your email address here:

    Comments / ONE COMMENT

    Hello,

    Have you tried using SmartDraw for project management charts? It works really well. They offer a free download trial from the website:
    http://www.smartdraw.com/specials/project-management-chart.htm

    Christine

    Christine added these pithy words on Feb 07 08 at 1:15 pm

    ADD YOUR COMMENT
    Comments are moderated.

    Adjacent Posts

Welcome to RodeWorks

Randall Rode's online home for thoughts, notes, and experiments with a wide range of technology topics. Visit the about page for info on my recent projects and professional background. I welcome your comments!

  • Recent Comments

    • Coming Soon

    New articles are normally posted on Mondays and Wednesdays. Subscribe to the RSS feed or the email update to keep current on the latest posts.

    Site Topics