Perfection Closes off the Process…

As we continue to consider the options between Google Apps for Education and Zimbra as an online email, productivity, and collaborative suite, I have noticed more articles about Google and the innovation methods that they use.  Yesterday I came across an article from the NYtimes that discuses  Google Pulls the Plug on projects that are going no where. The article was interesting in an of itself because it is interesting to see some of the inner workings of Google be discussed more openly (I will let others decide if it is transparency or calculated public relations).

Toward the end of the article this quote has caused me to ponder a few times…

“Perfection closes off the process,” Mr. Jarvis said. “It makes you deaf. Google purposefully puts out imperfect and unfinished products and says: ‘Help us finish them. What do you think of them?’ ”

It is pretty representative of a significant change in providing technology.  The willingness to take something less than perfect (because it is free) and work with it through various beta releases. Or more so waiting for the “beta version” to be released as that will be a stable release.  It wasn’t so long ago that beta wasn’t good enough for anyone beyond the true technology geek but these days it is different.

In addition to this thought, I reflected on how I led the roll out of Web Help Desk (or do any project for that matter).  I spent enough time figuring it out behind the scenes to work out the required  processes and to know it well enough to say this will work, then spin it through wider and wider circles refining the basic processes and and making sure that additional required functions are ironed out, then we start using it.  As we use it we refine it asking for feedback and taking risks to figure out what we didn’t know (or think about)  and use the users to help shape the technology.  I am not sure if this makes me user centric or if I just work at things until they are successful.  I wonder what it would take for me to pull the plug on a project?

Work Breakdown Structure

We are moving to the next segment of the project management session.

Dwight made the point of this is something that most skimp on but is something where the time and energy will pay off.

Start with major categories of work and then break it down into tasks.  It is so important as it allows you (and others) to know what needs to get done and if you are on task.  I bet people skip this step as they “know” what needs to happen and they will save time.  Much the same way that teachers (new and old) skip lesson planning.

Breaking down the task of assessment/e-portfolio project

Starting with a brainstorming session of all of the work that needs to get done.

Following the brainstorming try to arrange big buckets to assemble the tasks into.

The bigger buckets for this project were determined to be

• Project Management
• Infrastructure
• Training
• Support
• Communication

From this point you would need to work out if their are sub-buckets and then organize tasks under that and you then move on to the project scheduling.

dotproject.net is a free online tool (others are MS Project and Basecamp)

Which pieces of a tool are important

• Ability to Monitor Tasks
• Gantt views of a project
• Critical Paths
• Inputs for Multiple Teams
• Dependencies
• Resources assigned to tasks

Above all it is important to be able to show the project in “picture” format to the sponsor (which is normally at an executive level)

As project manager you need to be intimately involved in the project management software the question is how much do and who do you trust to have the add/modify/delete.  I think this is a floating line as team members and projects require different levels of authority/control/support depending on the circumstances and their role in the project.

Thinking About the Project Plan

Knowing your audience/team is paramount in developing a project plan.

In a project plan you should outline -

• Project Goal and Objective
• Sponsor -
• Stakeholder -
• Timeline – this normally is a killer of projects.  This goes with what ethan and I are talking about with deadlines are a project manager’s friend.
• Resources Required
• Deliverables
• Decision making
• Assumptions
• Risks
• Business process changes
• Project manager
• Project team
• Budget
• Signature

Your project plan is an official document but it is a work in process.

While it is important to know the details of each tenant of a project plan.  It is also of paramount importance to know thy self and accomplish your project planning within the culture of your organization and your style as a manager/leader.

Having a good relationship with consituents seems to overcome a lot of the personal/political organizational stuff of project planning.  – (aside – We need to get people out in the departments to get face time outside of of fixing problems.  How to do this?)

Live from Norwood; It’s Project Management with Dwight Fischer

The starting point is that understanding principles of project management is different than implimenting good project management techniques.  Every project is different and has its own set of problems and variables.

Some thoughts from Dwight’s presentation.

• A lot of IT projects come from the needs of others – This makes sense as Technology Services are a service to others on campus.  Typically it falls to IT to manage the process and project this also makes sense as Tech folk know the most about technology but what about the cultural part of the project.
• The life cycle of enterprise level technology is shortening.
• Framing the project and developing a good plan is a starting point as it give people a road map of what needs to get done to check of a project.
• How important is it to have a 30 sec speech on each of the projects you work on?
• A project is a temporary endeavor under taken to create a unique product or service.
• Someone is always in charge.  It may be that the person who is in charge needs to be reminder they are in charge so they can take on the leadership role.  (bottom up projects)
• Project management is about changing behaviors (need to think about this as part of the web help desk implementation).
• Knowing why projects fail is important to know as it helps you understand what needs to be laid out in the project plan.
• It is important to know what you are responsible for in the project.  Are you responsible for total success or just successful implementation.  This comes down to the issue of who is the sponsor or initiator of the project.
• A good charter process is going to tease out more questions and key points that need to be resolve.

Layers of Project Management

• Managing Self – understanding of ones role in the organization and how to organize the information and tasks you are responsible for
• Manage Process or Project – manage a single project
• Manage Multiple Projects – as you become a leader/manager you are probably at this level
• Manage Exex Attn & Decisions – When you are good at project management you get the attention of the top level administrators and thusly, their projects.

Reasons for Project Failure  -

• Failure to align project with organizational objectives
• poor scope
• unrealistic expectation
• lack of executive sponsorship
• lack of project management
• inability to move beyond the individual and personality conflicts.

First Attempt at Setting A Deadline

Computing Services is implementing a new call and asset tracking system that we are struggling to complete the installation for a variety of reasons.  At this point many of the other large projects that seemed to get in the way are complete or far enough along that getting Web Help Desk running is a more realistic priority.  

As the time is right to focus on implementing our instance, I am going to try and apply some of the project management principles (for lack of a better word) that I started discussion with Ethan.  I hope that blogging this will do two things.  

1. Get the project done.
2. Give ethan, you and I something to talk

We will see if either of those get accomplished.  I think that will but we’ll see.

In the meantime I think the starting point is setting a date and working back from there with milepost to see if the deadline is realistic or not.  

So here is the line in the sand.

We will start using Web Help Desk on January 2January 5, 2009 as our asset and call tracking system.

Now to think about what needs to happen backwards from there to make things happen.  I will post that in future posts.

Deadlines The Best Project Management Tool?

I started a conversation with a colleague from Reed College on some lite weight project management techniques.   As it was the initial conversation we meandered around a lot of topics that I hope we will revisit later.  A common thread was more about keeping people thinking and acting on the same page as opposed to which project management package works best.

Ethan posed a question to get at the techniques that I use to develop and meet the milestones and deadlines of a project.  My initial reaction is I don’t set deadlines but instead break the end goal into acheivable tasks and arrange those tasks into a progress that allows us to get the project complete.  I do this because most deadlines are arbitrary and when push comes to shove my project deadlines take a back seat to other priorities.    In most cases this works well as a monumental project because manageable by making it many smaller projects/tasks.  I think others get frustrated with me in this regard as my project upate reports are of what has been accomplished and what is left to be done instead of a nice and neat ETA for completion.

We chatted a little longer and Ethan brought up the point of how would it work for me if we started with a deadline – knowing that we might need to move it later – and then move backward through the progression of tasks to identify some earlier milestones that will help to determine where we are on the project.  In mulling this over, while I do not do that concretely I do do that in the abstract the classroom renovations we did this summer is an example.  Where the deadline is the first day of classes but for us to make that deadline we needed construction done by July 31 so that the technicians could have the time they needed to install the technology.  As the July 31 date came and went with a few rooms still needing carpet and such I knew that we needed to make contingency plans and start to reframe expectations with the registrar and prep the executive director of the potential calls he might be getting.  (In the end stars aligned and we finished everything some how)

Perhaps deadlines can be useful in keeping things on track…

I really look forward to continuing this conversation with Ethan (and anyone else that is reading this) on project management techniques that draw out that encourage collaborative thinking and building a common understanding of tasks and timelines.