Feeds:
Posts
Comments

Archive for the ‘Project Management’ Category

Most organizations recognize that their Project Management maturity is not what they would like it to be.  They may even have a vision as to where the organization should be for successful implementations.  After all, noone really questions the fact that increased project management maturity improves the odds of project success.  The problem is often not with the identification of the problem, but with implementation of the solution.  The typical response to solving this problem is to dive into PMI, Six Sigma, or CMMI and start creating mountains of methodology, processes, and templates.  All of these methods are very valuable if implemented wisely, but frustrating and distracting if implemented poorly.  The first step in maturing an organization is to validate and document the “As-Is” model.  Knowing how things are done today is required because you can’t measure improvement if you don’t know where you started.  Also, going from a very immature organization to an optimized maturity focussing on continuous improvement is not one step up and should not be attempted in one step.  Organizations need to understand that process and maturity changes are best accomplished through baby steps!  The hidden gotcha in these improvements is the company culture.  To improve process and mature management, the culture has to change and culture change is like manuevering an aircraft carrier.  It takes careful planning, persistence, and time. Planning to make drastic changes in methodology in a short time period can be mandated by upper management, but saying it and doing it is not the same thing.  Another factor in this challenging endeavor is the motivation of the employees.  If they do not see the benefit of the changes being made, it just seems like busy work to them.  Good employees don’t like busy work.  They like to be productive.  Small, deliberate changes pin pointed to show success can motivate people to get on the bandwagon and look for opportunities themselves.  These improvements can happen and do happen, but don’t fool yourself into thinking they happen overnight.  Remember, baby steps!

Advertisements

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

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.

Read Full Post »

Do you ever come to the conclusion that Project Management is not taken serious in the corporate IT world? I see many IT projects that have PM’s assigned, but they are not trained as Project Managers, nor do they have a background in project management. In these cases, they are usually Development Managers or Business Analysts who are given the responsibility of managing a project. It’s almost treated like project management and staff management are the same skillset. I don’t blame these managers. They usually have full time jobs andpmjuggle1 are expected to manage the project (or projects) off the side of their desks. It’s somewhat demeaning to the profession. It’s like an unwritten fact that Project Management is not difficult. From what I have seen, they do not aspire to be PM’s, or even want to learn how. I suppose someone has to do it and there are no PM’s on staff in the group, so the Dev Manager is elected. I think it comes down to the culture of most companies not truly understanding the value of a good Project Manager. PM’s are not just note takers, paper pushers, or administrators. In fact, a good PM can make the difference in a project being successful or not. As an industry, IT is still pretty new and could take some lessons from the construction industry. I have heard the argument about whether project management is a skillset or a profession. I think it is both. The professionals who take it seriously and truly learn the craft often become invaluable. The ones who just do it because they are told to, will get by I suppose.

Read Full Post »