Friday, October 28, 2011

I have a Zombie in my Project!?!



It is the season for Zombies and unfortunately they make their ways into our projects.  Zombies feed on processes rather than brains.   They think project management and organizational processes are like a cook book and they need to be followed.  The Zombies drag others down with their one way ideas.

Zombie protection kit:
1.        Get input from all team members on projects they have been on in the past that were successful and determine why it was sucessful

2.       Define what done means, or your project may never die

3.       If you have a process that is not working well change it

4.      Don’t feed the Zombie, point it in another direction to get it away from your project
 
So, what is Zombie PM?  Does this sound like someone you know?
  • They do exactly what they are told without challenging anything
  • They don’t come up with original ideas
  • They don’t suggest ways to improve the project management processes
  • They don’t follow up on actions – they simply assume they will get done
  • They update and issue the plan in a format that most of the team can’t read or understand
  • They work on projects that deliver no business value
  • They go through the motions of being a project manager but without any critical thinking applied
If this sounds like someone you have worked with – you know what Zombie PM is about.


Sunday, October 09, 2011

Box out your resources!

Currently I have 3 projects I'm managing.  One is the in initiation stage.  One in controlling.  And one in the closing.

For each of these projects I have different concerns with my resources.

For the project that I'm initiating I'm working with the resource managers to make sure I'm on their plan to have the resources I need based on my project requirements.  I keep them in the loop if things slip a little or if it looks like we may be adding scope.

For my project that is in the the controlling phase I have to box out my resources as others try to "get a little of their time".  There is a fine line with this, because many times you need to trust your resources to manage their own time so they can help out on other projects too.

In my project that I'm closing out I've kept the resource manages in the loop as to when I was going to release the resources so they could be assigned elsewhere.

This is a delicate yet complicated dance that we do as Project managers.  The key to this is communication with the project team and the resource managers.

Look ahead for your needs or you will be behind before you know it ....



Sunday, September 25, 2011

SharePoint Document Library Setup?


There are multiple ways to setup document libraries in SharePoint and you need to consider what is the best approach for your organization.  Here are some examples:

  1. Using folders in SharePoint.  Since the days of DOS we have used folders for separating out our files.  You can do this in SharePoint, but the intent of SharePoint is to have enough meta data tagged to your file so you can search or filter for the file you are looking for (just like you search for something on Google) instead of having them in folders.  The other downside of folders in SharePoint is that it makes security of libraries more complicated.

  1. The second option is to have multiple libraries.  An example of this is having a library for each department in your organization.  Again you can get into the issue of folks using folders again (you need to train people on what SharePoint is and can do, before you set them free using SharePoint).  If you can get them to not use folders, they need to get use to entering in a description for each file, and/or add your own columns of data you would like to capture (kinda like folder names, but now you can filter for those documents).  The issue with this is that we are so use to doing a save as, and drag and drop to a folder that this new step of adding meta data is a hard one to get folks to get use to.

  1. Next, taking the concept from above you can create “views”, which is nothing more then a filter.  At a previous organization I worked at we had 45 SOPs but not every person needed to read and understand all of them.  So we added a column to the library to indicate which job titles needed to review each SOP.  Then we created a View for each job title so they can see just their SOPs.  The nice thing about views is it really just ends up being a link to a webpage to the specific data you want to view.  So you can email this link or embed it in another webpage (so if we add SOPs to your link, it is okay, no need to update the link the new SOPs will just show up).  If you have files in folders within this library, you can forget using views to try to pull files from the folders.

  1. When creating a document library you need to keep security in mind (who needs access?) and do you want version control turned on? For those sensitive HR documents you can only allow a few key folks access to that part of our library or you can drill it down just to one document.  Version control, if it is on with 2007 every time you save the document it will create another copy of it once you check it back in (for some organizations they may have space concerns).  And with 2010 (I think) it will only save the new piece you updated (so, taking up less space then resaving another copy of the document).

  1. Alerts.  If you want you can set up email alerts be sent out when a new document is added and or changed.  Example: you have a project with a library and a view named Meeting Minutes.  When you add minutes to that view it will automatically send out an email to let your team members (you setup the users) that a new set of minutes has been added.  Or you can be that controlling person that wants to make sure no one is monkeying around with your files (so you receive and email when anything changes).

  1. Document Library template.  Yes, if your organization agrees to a new methodology for document libraries you can create a template for all to use.


Final thoughts …
So it is up to the users on how they want to use SharePoint, but you need to make sure they are aware there are other ways to do things in SharePoint than using folders.


A Beginner’s Guide to Document Management and Workflow in SharePoint

7 ways to effectively use a SharePoint document library

 

 


Sunday, August 14, 2011

Top 10 Reasons IT Projects Fail


Several months ago I started a new job and at my desk I found this top 10 list from Price Waterhouse Coopers:

  1. No clear objectives or benefits
  2. Lack of user commitment from business community
  3. Not managing the project proactively
  4. lack of coordination across change initiatives
  5. Optimistic deadlines and lack of contingency plans
  6. Not testing thoroughly
  7. Too many package software modifications
  8. Expecting people to develop and use a new system without adequate training
  9. Resource constraints
  10. In appropriate software and hardware selection

So what do you think is missing?

Sunday, July 17, 2011

What is in a Project Charter?

Recently I gave a short talk about project charters and I thought I would post my presentation here.

All projects, big or small, need to have a charter. It functions as a summary document at the start of a project.  If you cannot summarize things at the start you could be headed down the path to failure ...



Some other good links on charters:
http://www.brighthub.com/office/project-management/articles/5161.aspx
http://blog.method123.com/2009/06/03/create-your-project-charter/
http://www.youtube.com/watch?v=3J7urtEex6c

Monday, June 06, 2011

Career Development as a PM

About a month ago my company sent out an email looking for employees to submit short 5 minute videos about what they did to develop their career.  So I thought I would record one!

Here it is below:




Other links on PM career development:

http://pmstudent.com/how-to-focus-your-project-management-career/

Tuesday, May 24, 2011

PMI Madison Professional Development Day 2011

Recently I attended the Madison PMI Professional Development Day at the Monona Terrace. The theme was Great Leaders Building Strong Teams.

I attended many excellent talks and here are my thoughts on them.

The first keynote speaker was Barry Alvarez, Athletic Director at the University of Wisconsin.  Barry told many stories from his career as the Head Football coach starting with the challenge of changing the culture of a losing team to moving the mind set of his team to see it was not just Ron Dayne going for the Heisman Trophy but the whole team.  Finally he mentioned how he kept his team focused on achieving the WIN (What’s Important Now).

Lesson Learned:  If you are tossed into a loser ongoing project gather the troops and focus on what done is.



Next I attended at talk titled: Positioning Your PMO as an Organizational Alignment Engine by Terry Doerscher

Terry is the author of Taming Change with Portfolio Management (checkout my book review) and he started out his talk with some stats from a survey he has conducted a couple of times over the past couple of years.  The biggest eye opener in the survey was that organizational alignment was the biggest issue.  

Lesson Learned: If you don’t focus on alignment your organization and projects will continue to flop around.

Then I attended a talk titled: Implement a PMO – Lessons Learned by Mark House

Mark went over two examples of PMOs that he created.  He came from a very structured PMO with State Farm and then he moved on to take on a job with the state of Illinos to help one of their departments create a PMO.  Mark came in with a tool box full of templates, policies and how to’s, but quickly found out it wasn’t going to work.  He stepped back and slowly rolled things out like an agenda template and status reports.  Also he found out the super formal way that worked for all projects at State Farm wasn’t going to work, so they came up with a PM Light version of their PM process and trained all project members on project management.

Lesson Learned: Adapt project management to the organization, then adapt the organization to project management.

Then I attended a talk titled: Dynamic Scheduling with Microsoft Project by Ted Barth

Ted went over the basics of using Microsoft Project.  From setting up a calendar to making sure you build your timeline like a network diagram (you need a start task and an end task).

Lesson Learned: If you stick with the basics your timeline work correctly.

Then I attended a talk titled: Influence and Persuasion skills for Project Leaders by Chris Hinrichs.

Chris reviewed his views of project leaders which included those who know how to inspire, influence and impact others in a constructive and supportive way often go the furthest and the highest.

Lesson Learned: Practice the fundamentals of leadership and you will be in a better position to excel.

Finally the second Keynote speaker Mark Johnson spoke.  Mark was on the 1980 US hockey team is the current UW Women’s hockey coach.  Mark Reviewed his career in Hockey and told some stories on how he motivates his team.

Lessons Learned:  Even if you are a coach, sometimes you need to be a cheerleader.








Saturday, May 07, 2011

Review of Planning Force Project Planner …



It has been awhile since I reviewed a project planner so I thought I would take Planning Force for a spin.

On their main page there is an 8 minute video that gives a nice overview of the product and there are several other short videos on their YouTube page (I’m not sure why they want you to register to view their youtube videos on their own webpage or why many of their videos have no sound just a person clicking around in their application, or why you have to register to review their forums).

Their express planner is a free download (100 meg file).  Many other applications like these are cloud based.  The main issue I have with stand alone products are updating them.

After I had it installed I started clicking around and checking it out.  Overall it is a very very basic project planner with resource allocation capability.  The planner is pretty straight forward to use and the resource planner is too.   It also will allow you to see the resources from multiple projects saved in one file (they must assume companies only have 1 PM running all of their projects?).

It has a resource leveling function that will give you options before you move forward with their suggestions.  No clue as to how it works, but most projects I have ever worked on the resources don’t have the knowledge to jump in if they have some free time. It does have a calendar feature so you can track your staffs vacation (or holiday) time.

At the task level you can do some very basic things, number of days (or 0.5 for 4 hrs), start and end dates, predecessors (lead, lag if needed), percent completed, add notes to the task and the resource name.   What it is missing from this section … costs for the task planned and actual (not all projects track this… but if you are looking to do a little earn value analysis…) and how about I can create a column and let me name it myself?

Pros to Planning Force:
  1. Free
  2. Resource tracking so you can see if you are over allocated across all projects (keep in mind all of your projects are in one file)
  3. Basic project planning
  4. has some basic KPIs

Cons:
  1. Very very very basic
  2. Probably not that useful for projects with staff that work outside of your office (all projects have some basic documentation (SOW, charter, WBS, requirements, Risk log, budget info …)  and this application doesn’t allow you to store that type information.
  3. No communication tracker … message board, or a newsfeed type of feature (@task has this and you will see more and more PM software adopting this soon).

Friday, April 29, 2011

How do you continue to grow as a Project Manager?

So you are a PM and have been for years right?  You have your PMP certification and you are always on the lookout for PDUs, right?  Then maybe you obtained a Six Sigma certification or some other certifications …  now what is next?!?

If you find yourself in this rut here are my tips:

Start up a PM Knowledge Book.  It can be a binder or an electronic means to capture information.  Save interesting articles, links, how to’s or even fun games you have tried out in some of your classes you have attended.  Another possible way to do this is start a blog.  I cannot tell you how many times I’ve gone back to my blog to review something I wrote up after someone asks me a question on a certain aspect of project management (all of those links to other good pieces of information are also very helpful).

Get more training.  Look for different classes in things like communication, finance, business and taking a refresher course in Microsoft Project every couple of years cannot hurt!

Read blogs, books, magazines, listen to podcasts, and try out new trial versions of PM management tools.  This will help you to keep up on the ongoing trends in project management. But when will you have time to do this?  Schedule time for yourself and pick a couple of  blogs or podcasts to review every week.  After you do it for awhile you will start to get use to your new routine.  And you may surprise yourself as your thoughts flow out into the comments of blogs you’re reading (see you are now really getting involved).

Network with other PMs, ask them how they manage their projects. You can learn a lot of things from seasoned PMs.

Review profiles of PMs on linkedin and see if you can find new ways to build your profile (or resume), or you may find out about classes others have taken or purpose a question to the community for feedback.

Finally, give back. Whether it is mentoring a PM, working with your local PMI chapter, or donating your time to manage a community project.  Once you get to this stage that PM Knowledge Book you have been keeping will really pay off!

Notable quote:

An investment in knowledge pays the best interest.
-Benjamin Franklin 


Sunday, April 10, 2011

Mentoring Project Managers


Over my career I’ve had several opportunities to mentor project managers and recently my local PMI chapter put together a mentor/mentee program.  I decided to toss my hat in the ring as a mentor and shortly after that they matched me up with Joe.

My first meeting with Joe was super informal.  It was a meet and greet where we went over our backgrounds, what was going on in our lives and what we were expecting out of this program.  Like any good meeting we both left with a “to do” list for our next meeting.

At our next meeting we started with a little show and tell with what was on our “to do” lists, came up with some things for next time and ended with a little coaching on how to persuade the deciders on doing things a new way (new PM process).

I do truly enjoy the opportunity to work with others to see how their organizations are running projects and hopefully I can learn something and they can too.

My tips for mentoring PMs:

Feedback!  Ask them to request feedback from their team members and information on how the project management process is going in their organizations.

Roll play!  All PMs have team members that will be confrontational on an issue.  My suggestion to help them is to find someone to roll play with so you can practice on how the decision will go down.

Crisis!  When the big issue comes up in your project, take a deep breath and then get the right people in the room (on the phone) to discuss it.

Communication!  You need to be a master of communication and if your team is not aware of what is happening in your project you need to come up with new way to communicate project details.

Training!  If you are new to project management or you already have your PMP or other project management related certifications you need to keep building your knowledge and keeping it fresh!  There are a ton of classes, books, podcasts and blogs out there to help you with this.  Many times scheduling a class for a PM will keep them focused on building their career with their current organization.

Note able quote:

"Be the change you want to see in the world." -  Gandhi

 

Wednesday, March 16, 2011

Too many projects … not enough resources


Over the past couple of months I have had several discussions with companies and groups about their list of ongoing projects.  Some of the questions I asked them are:
 
  1. Do you have a list of all of your projects (you would be surprised how many said no …)?
  2. Do you rank your projects, and if so how are you ranking them?
  3. Do you really have enough resources for all of your projects?  If not, why are you trying to do them all at the same time?
  4. Do you review your projects, let’s say, quarterly to make sure you are focused on the right ones and to cut the ones where the market place has changed?
  5. Do you have this list in a common location for all to see (again, you would be surprised how many said no to this … really?)?

The key to making this ranking system work is having the correct ranking criteria for your organization prior to sitting down with the ‘deciders’.  The ranking criteria will include things like project performance indicators, business value indicators, looking at the resources needed and finally things that are deemed important by your organization.  Here is a short presentation that I put together using some of the concepts from a presentation by Barbara Schrage.








Once you have your rankings in, the debate is on to see if everyone agrees.  The key is you want to have a balanced score card for your organization.  Glen Alleman recently posted an excellent presentation on this topic:








The key to making this work is having something in place to rank your projects and a reason why they are ranked the way they are.  Otherwise the top projects in your company will be someone’s pet project which may not help the strategic vision of your organization (I like to call these the chest thumper projects or the, whoever is the loudest has the highest ranking project).





Thursday, March 03, 2011

How to do you measure the maturity of a SharePoint implementation?

So your organization is thinking about taking the leap, or already has, into launching SharePoint.  When you started on this adventure you treated this as a project, right?  Or did you just turn it on and send out an email stating, “SharePoint is now available”.

If you don’t treat it as a project you are headed for an early disaster and users won’t want to use it. 


Five most common mistakes when rolling out SharePoint:
1. Lack of proper planning
2. Showcasing Features; not building solutions
3. Undefined business case
4. Poor understanding of SharePoint
5. Unrealistic Staffing


The key to adoption of SharePoint is to start out small with one department and bring in those team members that are typically the early adopters.  As you build up the first site you will also need to build your training documents and start to train the people that will use the site.  Then you need to continue training, re-training, start to add articles to your company’s newsletter or blog about SharePoint and finally if it is a requirement to move away from the old paper way, monitor your staff to make sure they made the switch.

Once you get to the point that your company is making the switch over to SharePoint we need some metrics to determine how SharePoint is maturing within your organization.  About a year ago some of the big name advocates of SharePoint started this discussion.  And recently Sadie Van Buren has been giving talks about how she determines the maturity of a SharePoint system in an organization.  Below is her template to determine the maturity of a SharePoint system.



And here is her presentation that shows some examples of 100 and 500 level SharePoint sites, and she also gives an overview of each area and what she thinks is a 100-500 level of maturity. 



Also, recently Dux Raymond Sy brought together 4 SharePoint advocates (including Sadie) to discuss “Understanding the SharePoint Maturity Model” 





In my own organization I’ve seen our SharePoint sites go from only a couple hundred clicks a month to now over 130,000 clicks per month.  That is a pretty impressive jump and we are only at about the 300 level of maturity. 

"The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn."  -  Alvin Toffler

 
Captain Kirk reviews his ship's status on a dashboard made in SharePoint


Sunday, February 27, 2011

Project Management is about the People not the Tools


This past week I attended my local PMI monthly chapter meeting where Bob Baim gave a talk titled, “Predictive Project Management, Strategies for Avoiding the OS Phase” (Bob also has a book with the same title).

Bob (a very energetic speaker) gave us many examples of big name projects that hit the OS phase, and in many cases, they hit it again and again.  One of his take home messages was that projects do not fail, processes do, and if you do not fix them you will fail, again and again.

The following slide sums this up nicely:


You see it is not all about the tools.  To be a truly effective PM you need to be a people person and you need to be an expert in all types of communication.  Reading the PMBOK and being able to quote the page number where they talk about the WBS doesn’t mean you are an effective PM.

Josh Nankivel, from the PM Student, had a recent quote that I think sums it up nicely,

“I think many project managers tend to focus on tools and techniques far too much, and not enough on the people aspects of managing projects. By far these relational aspects of project management are the most important ones.”

Final thought on this.  Please keep in mind the people in your projects are what make your PM tools useful.  If you spend all your time with your tools you will probably be headed to the OS phase …


Sunday, February 20, 2011

Project Planning Poker



Last week I attended a meeting with the group Agile Madison where our topic of discussion was determining the duration for each sprint item.  My input on this was that a plan is a strategy for the successful completion of the project and a schedule will tell us when things will be completed.  I also reviewed some ways to determine the schedule (or duration) for tasks in a project (Agile or any other type of project management methodology).  The classic PMI ones are: historical information, 3-point analysis and Monte Carlo analysis.  

The one that was introduced to the group was Planning Poker.  Here is how it works.

If you have a project with a group of developers (or testers, or data engineers) each developer is given a stack of cards that have the following on them: ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.  The PM (or scrum master) reads off the sprint item and then the  developers pull out their cards on how long it should take and then they flip them over at the same time.  You may see instances where they all closely agree and other times one person is way off.  This will help them to open the channels to discuss why they picked there duration (maybe one of them had a similar task in the past and knew it was a lot more work then it was first predicted).

Why does this work?

It works because it allows you to bring together a group of experts to discuss each task and in many cases you may end up averaging the numbers to come up with your best guess as to what the reality may be.

So the next time you find yourself in a situation like this, think about pulling planning poker out of your PM toolbox.


Friday, January 28, 2011

Five tips for managing worldwide project teams

Recently I attended a talk titled: How to Create and Manage Remote Project Teams by Wayne Turmel and I thought I would write up my top 5 things to keep in mind when you come into this situation.

1.    Use Web 2.0 technologies

 

In order for your team to use these web based technologies they need the right equipment to do their jobs (high speed access, laptop, cell phone …).  Without the right tools they will not be able to complete their job.

Pick the right technology for managing web meetings, documents, communication, timelines and if necessary timesheet tracking.  Not only is it important to have the right technology you need to train your team members and make sure they are using it correctly.

 

2.    Pick the right team members

 

Granted, many times you don’t get to pick your team, but if you do, focus on people that are self motivated, have good communication skills and are result driven.  By picking people that are open go-getters it will help increase the chance of having a smooth project.

 

3.    Determine your team's purpose

 

With team members all over the place you need to define your team’s purpose and set the ground rules.  You can do this with a Team Charter.  The Team Charter is a document that defines the purpose of the team, how it will work, and what the communication expectations will be (maybe each team member needs to update the project site daily on what they are working on).

 

4.    Reward Performance and give feedback

 

Have you ever been on a team and feel that they forgot about you?  Multiply that by 10 when you have offsite team members.  To help combat this, you the PM, need to set up regular reviews of your team members and if possible try to call them up once a week to chat.

If your budget allows it, setup a rewards system, but make sure it is fair for all team members.  Many times these rewards are setup for project goals and it will help keep the project on track.

 

5.    Incorporate some team bonding

 

If you have the budget the best way to do this is to have a several day face-2 face meeting that includes some offsite fun.  If there is no budget, then it could be something as simple as having a page within your project site with photographs of the team members (maybe you mix it up and ask them to include a photo from grade school), a bio, and links to things like their pages on Linkedin, Facebook, Twitter or even YouTube.  

 

Monday, January 17, 2011

Agile Will Be Seen for What It Is…and Isn’t


A new year is here and one of the top trends for 2011 will continue to be where Agile project management is going.

In a recent blog post by Bernardo Tirado his top trends in project management for 2011 includes a statement about Agile software development:

Project management organizations embracing Agile software and product development approaches will continue to grow while being faced with the challenge of demonstrating ROI through Agile adoption. In addition, they will need to disabuse their stakeholders and executives of the expectations set by IT consultants, the media and the vendor community that Agile is the next “silver bullet.” Organizations that do it right – including selecting the right projects for Agile – will reap significant rewards.


The key is selecting the right projects for Agile project management … but how?  

Recently, I attended the Madison PMO Manager forum where we discussed this topic.  One member mentioned that his organization completes a risk assessment on the project to determine if it is the right fit for Agile project management.  Others indicated that it works well for small projects (making a web app) with small teams that are co-located.


You selected a project but how to you measure it?

This is where it gets interesting.  A PMO has many metrics it tracks its projects for, but with Agile project management you typically only have a burndown chart that is really nothing more than a chart showing 100% down to 0% complete.  


We want more, right? 

One way to make measurements is to use the Agility Measurement Index which scores developments against five dimensions of a software project (duration, risk, novelty, effort, and interaction).

A second way to is track the goals that are set for the project.  Without objective measurements you are just guessing!


Why does Agile project management work?

1.     The stand-up meetings holds your team accountable.
2.     Rapid development of semi-functional software allows you to keep the project going in the right direction and there is less of a chance of it going down the wrong path.
3.     Having experienced developers that have coded similar items and expert users as your primary stakeholders will help to keep the project focused.
4.     Do the right things!  If the post-it notes methodology works and is appropriate for your project stick with it.  If you are developing software that is regulated and you need some or a lot of documentation, make sure you create the necessary documentation.  You cannot have a one-size-fits-all Agile process.


Notable Quote:
“The agile processes that are successful have players that "know" what to do from skill and experience.” -Glenn Alleman