Do you ever feel that many Executives do not fully understand what Project Managers do?  They think the Project Manager and the Resource Manager have the same skill set?  Granted, that some characteristics of these jobs do overlap.  Both require good communication skills, the ability to build relationships in the organization, and the know-how to get things done.  But there are also some very distinct differences.  Resource Managers, by definition, manage the resources directly.  The resources work for them and as their boss, control their day-to-day activities.  Project Managers must try to manage a body of work with resources that do not work for them and have no control over their priorities.  This brings us to another difference, priorities.  The Project Manager’s (PM) main objective is to get the scope of the project completed within the timeline expected without compromising quality.  This objective is very defined and becomes their number one priority.  The PM gets rewarded for moving fast and checking things off the list.  The Resource Manager’s (RM) objective is much different.  Since they often own the support of a product once it is implemented, this project adds work onto their already busy plate.  Some RM’s may even resist a projects progress because of this fact.  At the very least, they want to ensure that the product is stable and supportable.  After all, it is their team that will be up in the middle of the night supporting a problem application after the PM has moved onto another project.  The RM is motivated by quality and this project may not be a top priority because their priorities change daily.  They are also managing support problems and maintenance tasks.  So there you have it, the PM focusing on schedule, the RM focusing on quality.  The PM must drive things forward with a single purpose, plan for every possible risk, and methodically overcome obstacles as they arise.  The RM must juggle constant issues that arise, react to the changing direction of the products they support, and respond to staffing problems like turnover and sick time.  These are very different jobs that require different backgrounds and skill sets.  To lump them together is an insult to both.  All levels of an organization need to be educated as to the nature of Project Management and what the job entails.  Only then can they give the PM’s the support they need to be successful.

IBM recently announced the creation of a consulting services group that focuses on helping customers make better and faster business decisions, presumably using data to make decisions instead of instinct or “gut feel”.  This is not a new concept, although I do agree with the concept for the most part.  There are many business changes that can be made to save the company money and good metrics help you to realize those savings.  Things like reduced calls to a call center, call time reduction, and reduced truck rolls can easily be measured and improvements result in cost savings.  Using metrics to make decisions is just smart management and today’s data warehousing and CRM systems give us more and more data to analyze.  But let’s not forget the variable that never changes, the human factor.  Our employees, our customers, and our vendors are all human and because of that, there is an additional variable that is difficult to measure.  Things like customer satisfaction can be measured in surveys or sales volumes, but it is difficult to really know how loyal your customers are to your company.  Just because they are happy with their service, does not mean that they won’t jump to a competitor for the right promotion.  Can you really measure the overall satisfaction of employees?  Some employees are hesitant to be blunt  and you usually hear complaints from a few vocal employees, not the general population.  How about applying metrics to Project Management.  Sure, you can measure whether or not you met a deliverable date, but if the dates are renegotiated with a customer and the customer is happy with the change, how do you categorize that data point?  You missed the date, which is bad, but the customer is not upset about it, which is good.  My point is that some things in business can be easily measured and we should take advantage of that data.  Others are more difficult to measure and trying to shoe-horn a one-size-fits-all solution to all problems can be problem in itself.  Some things are best measured with experience.

Our company implemented Microsoft Project Server 2003 a few years ago and last year, upgraded to 2007.  The tool is well suited for managing projects, which is why the Project Client is the industry standard for PM’s.  The Project Server gives you a centralized view of all projects, essentially a Portfolio View.  It also gives you the ability to view most data through the Sharepoint interface without requiring the expensive client (for non-Project Managers).  In addition to these benefits, we targeted our biggest pain point, the problem of capacity management.   Assuming all your resources are in the system, the data for managing capacity already exists, there is just not a good way to manage from it.  To address this, we built some custom reports that pull data directly from the SQL Server database.  In these reports, we can view all tasks for a specific employee, overdue tasks, and a chart that displays the next six weeks of workload across all projects and resources.  To account for the non-project work that we were competing with, we created a maintenance and support project schedule to block time needed for these activities.  We also created an administration schedule to track folks that are out of the office for vacation and training.  Adding these schedules gave us the total picture of resource capacity.  The system works rather well.  The PM’s now meet weekly with all the Resource Managers weekly and we look at all resources over capacity and negotiate.  We also talk about overdue tasks and how to address them.  This method does require that all PM’s manage their plans daily to keep the data accurate, but the benefit to the organization has been tremendous.

Since the 1950’s when the Work Breakdown Structure and Critical Path Analysis were developed, there have been a lot of developments in technology, tools, and management techniques.  But there has not been anything created to replace the benefit of a work breakdown structure (WBS) and a critical path analysis (CPA).  We recently implemented these as a standard on all internal projects.  Our version of the WBS is very simplified, outlining the major deliverables that are in scope for the particular project.  These deliverables become the focal point throughout the project.  They are summary tasks in the project schedule (Gantt), they are on the project web site with planned and actual dates of completion, and they are the primary communication of project status on our status reports.  The PM will create the initial draft, get contributions from the core project team, then get approval from the customer.  If these deliverables change, it is a scope change which impacts the schedule, resources, budget or all three.  We then take this WBS into a meeting with the project team and do a CPA session.  We use a non-tech approach by literaly using sticky notes for tasks identified by the team, color coded by resource type, and stick them on a whiteboard.  Always starting from the end and working backwards, we go step by step and selecting which task that has to happen just before the prior task.  We draw the different paths, estimate work effort and duration for each task, and identify critical path.  In a two hour session, the PM walks out of the room with enough data to create his/her project schedule.  To speed up this process, we created a “Service Catalog”, which is basically a project schedule with activities that are common to the organization.  By flushing out the details of these repetitive tasks as a pre-approved standard by the organization, the project teams do not need to recreate the wheel each time, but only focus on the new items for this project.  By using these methods, you can develop a project schedule in a very short timeframe.  It works well with an agile or Lean project approach.  The old methods are sometimes the best methods.

The concept of a “Servant Leader” has a long history going back thousands of years and is documented very similarly in many cultures, most notably in the Bible in Mark 10:42-45.  In modern times, it was made popular in the 70’s by Robert Greenleaf when he published an article called “The Servant as Leader”.  There are a multitude of books on the subject, but basically it deals with the motivation behind a leader.  Many leaders approach their position with a top-down hierarchical style of management.  They are in charge.  It’s their way or the highway.  Instead, servant leaders see it as their role to put the individuals in the organization first and choose to lead in order to serve, not to increase ones own power or title.  Servant leadership stresses collaboration, trust, and teamwork.  This is, however, a concept that has often gotten lost in the corporate world of politics and ladder-climbing.  A servant leader sees it as his/her responsibility to enable the success of his/her team by promoting the growth of the individuals on that team.  It is such as simple concept and has a centuries long track record of success, yet seems all too rare in today’s Corporate world.   The hurdle is over coming the one-up-manship that tends to drive trust out of a culture.   Organizations that promote teamwork and encourage collaboration will have teams of employees that trust one another, which in turn, work more efficiently.  In today’s economy, anything that improves efficiency warrants some attention.  A company that can develop this type of culture also has happier employees, which means less turn-over and the reduced cost of replacing those employees.   All in all, sounds like a no-brainer.

I was reading an article yesterday about the new Intel Xeon 5500 chip and how it was designed to run virtual machines more effiiciently.  If this advancement plays out in reality the way it does in theory, it could change the industry and make the “Cloud Computing” concept a reality.  Entire data centers could be run from a couple of racks of equipment.  For me, the lightbulb really went on!  If users truly run all their apps from SAAS vendors like Google apps that run completely from the web, and store all their documents and digital pictures on web storage, then why do they need a computer?  All consumers will need is a browser interface to the web.  All the new gaming systems can connect to the web.  Why not add an interface to your TV?  Thinking this was a concept for the future, I did a quick Google search and found out that Sony is releasing internet video-ready TV’s that can access web content without a computer.  OK, I guess I am not such a visionary.  In my lifetime, I have watched stereos systems get replaced by Ipods and docking stations.  I have seen records evolve into cassette tapes, CD’s, then all digital media.  Next we may see the “end of days” for computers.  We’ll only need portable devices and our HDTV’s.  It’s a good time to be alive 🙂

I have worked at companies that were in start-up mode.  Describing the way they work would be “managed chaos” at best and everyone wears many hats.  Everyone works long hours and does whatever it takes to get the job done.  This is what it takes to be competitive.  When these companies start to grow and become successful, they get to a point when they need more structure.  After all, you can only survive working “without a net” for so long.  They build frameworks and processes and get more rigid about job responsibilities.  They introduce ITIL, Scrum and Six Sigma to measure process improvements and things do improve, at first.  Simply by paying attention to these things and making them important, things DO get better.  Then somewhere along the way, they stop focusing on the customer and start focusing on the charts or the procedures.  After all, when employees are penalized for bad data on charts or for breaking process, they do what their survival instinct tells them to do, manage to the data.  This is where the pendulum swings too far the other way.  Instead of employees focusing on innovation and adaptability, they focus on not getting in trouble.  They become trained NOT to stick their necks out or take chances, because risk breaks things.   Slowly the processes become bureaucratic and it is increasingly difficult to move projects forward.  They become victims of their own processes and everything has to be escalated to get things done.  Don’t get me wrong, I am a huge advocate of continuous process improvement and standard processes, but you must always keep perspective on your big picture goals.  Any good process should have an exception policy because there will always be exceptions and yes, there are appropriate times to break all the rules.  Process should be a tool to help you improve, not handcuff you.  Be careful when creating all this structure that you don’t stifle the things that enabled your success in the first place, agility, adaptability, and customer focus.