Yellow Lines and Dead Armadillos

| 3 Comments

As an IT team member at Penn State, I am never far away from Projects and Project Management practices. Many people think that project management is about managing time, money, task lists, you know, the details. It is partially about these things, but mostly good management is above making decisions and staying focused. There is a delicate balance that must be maintained when you are managing a project. On the one-hand you have a goal or list of goals that must be completed, and on the other hand you are one person who cannot succeed without the help of others.

Over the years, I have participated in quite a few projects both as a team member and as the project manager. The projects that succeeded had some things in common.

  • Defined goal(s)
  • Defined deadlines
  • Defined scope
  • Dedicated team

They didn't necessarily have Gantt charts or extensively detailed plans. Remove any of the above list and the project will flounder. Another good way to kill a project is to rule it by committee. I don't want to discuss indecision by committee today, but it you want to read more on that check out this post by Mark Linton.

I want to talk about making decisions. Someone must make decisions. The listed definitions cannot exist until someone says, "Make it so." One of the sites I frequent, Mavericks at Work, had a recent post about indecisiveness and failure. The post discusses how and why companies should avoid being in the middle of the road. You don't have to be a manager to make decisions. Every project team member needs to make decisions to get their respective jobs done. Managers need to decide what the priority project is. To quote Connor MacLeod of the Clan MacLeod, "There can be only one."

We are currently working on upgrades for our core VoIP applications. We have two applications that are tightly integrated through a proprietary vendor. To maintain supportability with the vendor, we have to upgrade to more current versions. Here is my Cisco Unified Communications Manager 6.1 and Cisco Unified Contact Center Express 5.0 upgrade project outline.

  • Defined Goals
  • Upgrade both applications to new versions.
  • Prevent service interruptions.
  • Manage Expectations.
  • Defined Deadlines
    • We will perform this upgrade over Winter Break 2008.
  • Defined Scope
    • Software will be upgraded to new versions. That's it. No new features, no service changes, no redesigns. We will take exactly what we have today and make it work on the new version.
  • Dedicated Team
    • Remember what I said about missing components. We don't have resources dedicated to this project as top priority. I am working as much as I can as are my peers, Doug Dreibelbis and Bill Simon.

    Hmmm...I am apparently not following my own advice. Well, we will just have to make that Dedicated Team thing happen. My first official action toward getting that dedicated team item that needs help is to end this post and get back to the project. Thanks for reading. Extra thanks for commenting.

    3 Comments

    You left out the side loop under "Manage Expectations" that goes back to re-Defined Goals. In this case, there used to be a goal of stability at every step in the process, and that is gone now. The management occurred in the seldom-used path of "Empowerment" where you told your boss NO - it can't happen that way. Fortunately he listens to reason. Also under Dedicated Team, you need to consider adding "kill off the opposition", or "find a cooperating vendor sales force", or whatever applied to what you did on the phone call earlier this week. :-/
    That's a good loop to include John. What I had in mind for managing expectations is that since this is new software, and software "always" works as advertised, we should be prepared for disruptions. I would distinguish disruptions from interruptions in this way. A service disruption would be changes to menus or web interfaces that we have gotten used to seeing a certain way. A service interruption which I consider unacceptable would be a complete loss of calling capability.
    I can relate to your concern on the dedicated team. I will trust you when you say it applies to the case at hand, but it is really a systemic issue. We all have full-time jobs. Otherwise, we would all be somewhere else. When there is something "new" to do, it is mostly volunteer time. The "team" you create only exists because you made it. That makes you dedicated. That is wonderful. An employer can say, "You are an exempt employee. You should do what it takes to get the job done." They would be right. However, it would be better if there was an institutional commitment to the team. We talk about project management strictly in a scholarly sense. It does not map onto any formal structure within our workplace.

    Leave a comment

    Call Chris at Work

    My del.icio.us Network

    Subscribe

    Join my Facebook Blog Network

    Creative Commons License
    This blog is licensed under a Creative Commons License.
    Powered by Movable Type 4.21-en

    About this Entry

    This page contains a single entry by Chris Kauffman published on August 15, 2008 12:46 PM.

    Why does Penn State use real IP Addresses? was the previous entry in this blog.

    Blogging is hard so I will make it harder is the next entry in this blog.

    Find recent content on the main index or look in the archives to find all content.