jump to navigation

A project is more than a schedule April 26, 2015

Posted by Edwin Ritter in Project Management.
Tags: , , ,
add a comment

There are many things involved to run a project. Documentation, people, time and money are always involved. As data sources, they are used to develop a project schedule. To manage the tools and processes, a project manager needs skills. Hard skills, soft skills, people skills and technical skills are a few.

Sample schedule

Sample schedule

As a PM, one of the simplest questions asked is “What’s the schedule say?” A good schedule provides the data on what’s done, what is being worked on and what’s left to do. The schedule easily answers the question “Where are we?” Variations of this include “Are we there yet?” or “What’s next*?” and “How much longer?”

*A favorite of mine, especially when asked by someone on the team. Shows commitment, dedication and confidence on their part. Always good to have those people on a project team.

At times, I have seen an over-reliance on the answer of what the schedule ‘says’ by a manager or customer. Heresy, I know. Don’t get me wrong. I am all for planning, scheduling and getting tasks assigned to dates.  But a project is more than a schedule.

The schedule is one part of the project. It shows where you’ve been, where you are and where you are going. Other parts of the include budget, resource allocation and responsibility. Combine those with the assumptions, risks and choices made that then result in a project.

When someone asks “Well, what does the schedule say?”, it says to me that they don’t agree with what they heard. Expectations are not met and something must be wrong with the schedule. When, not if, a PM is then asked “What is wrong with the schedule?”, the answer(s) should be “Here’s what is wrong with the project that results in this schedule.”

There are ways to find out why a project is not aligned with the schedule. From a previous post, here are six signals to review.

What’s your take? Comments invited, as always.

 

Ruminations on Change Control October 22, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , , , ,
1 comment so far

It seems that no matter how much project experience you have, how talented your team is and how simple or complex a project is, there is one thing that will always be constant and that is change.

Previous posts of mine have dealt with setting up projects, closed loop feedback and the value of PMOs. Another basic process to define and get agreement on while setting up a project is how to handle change. The concept again applies to ITIL, Project Management and Lean Six Sigma areas. The level of process to use in review and accept/deny changes can be proportional to the complexity of the project. Simple projects don’t have many changes while complex projects can have multiple changes. This relates to the fact that we make decisions and plans at a point in time. As the project goes forward and we get smarter in the future, we may need to revise our plans and that can lead to change.

programming-change-management-processIn fact, during the planning phase, the process details should be documented to submit a change, review and assess the impact to the project. There are as many ways to deal with change as there are organizations. Having a consistent way to deal with and manage change(s) to a project is essential when change occurs. This chart illustrates the basic concepts as just one example of the process.  Using a common repository, change log or application to create the change record is a good practice also.

The PM works with the project team to provide an impact assessment and a recommendation on the change.  That decision should be reviewed with the sponsors. Each change should be assessed for impact to the schedule, resources and budget. Here are six steps to control change:

  1. Record / Classify – capture the request and indicate what area(s) of the project are affected
  2. Assess – review the impact to the cost, schedule and resources to implement
  3. Plan – update project documents as appropriate based on the assessment
  4. Build / Test – execute the change and determine effect to the rest of the project deliverables
  5. Implement – include as part of the project deliverables and release at go-live
  6. Close / Gain Acceptance – complete the documentation on the request and communicate with the team and stakeholders.

Using the process framework provides a way to control changes for a project and the rate at which changes are generated.  Here is where the process helps in that it provides a way to accept or deny changes. Completing an assessment of the change and updating plans result in data to support the resolution to the change request. Not all changes are created equally. Some can be rejected outright and from other requests, it is clear to see the benefits.

Last, during project wrap-up and lessons learned, the number of changes submitted and their resolution can provide some interesting insights. How many were submitted? Accepted? Did the changes requested indicate a gap with requirements? Was the project not planned properly? Was the design not fully thought out? Those questions and others can lead to animated discussions. The key is which ones to action and improve on going forward.

Of course, that could be a change request also. How do you manage  and control change? Does the process impact your project in a big way? What happens if you reject a change? Comments invited.

Ramblings on RACI Matrix for Projects September 25, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , , , , ,
4 comments

A lot of things need to occur to get a project started. For the project manager, understanding the basics about the project – the goal, timing, budget are some of the tasks to getting organized. Included in that understanding is who will do what tasks for the project.

A great way to get organized and develop that overall understanding about the make up of a project is to document. No, really, it is. There are several basic documents that come to mind. As separate and distinct files, those include the scope, charter, schedule and raci matrix. Each of these is important for upfront planning and also during execution of the project. I have found that writing or contributing to each of these is very helpful. Being able to communicate the knowledge of  the what, how and who during a project kick-off meeting helps get the team up to speed quickly. Most of the documents are easy to understand conceptually by their title. The last one, the responsibility matrix thing, might be a bit unclear.

Six-Sigma-RACI-MatrixEssentially, the raci matrix lists who is responsible for what on a project. As an acronym, it stands for Responsible, Accountable, Consulted and Informed. A brief definition of each will assist in why this document is useful for the project manager, the team and stakeholders.

Responsible – Those who do the work to achieve a task. There is typically one role with a participation type of Responsible.

Accountable – Those who are ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom Responsible is accountable. Typically, the Process Owner is Accountable for a process, and there must be only one Accountable specified for each task or deliverable.

Consulted – Those who are not directly involved in a process but provide inputs and whose opinions are sought.

Informed – Those who receive outputs from a process or are kept up-to-date on progress, often only on completion of the task or deliverable.

There is a variation that includes another role for support. There are templates available for a RASCI as well. The ‘s’ stands for support and the definition is :

Support – Resources allocated to Responsible. Unlike Consulted, who may provide input to the task, Support will assist in completing the task.

=====================================================

The RACI matrix is not only used in project management. It is used in other IT processes and methodologies. The RACI matrix is part of the ITIL process for service design and driving service improvement. For Six Sigma methodology, the RACI matrix reflects the basic principles of the process.

Having a RACI helps everyone understand the specific interactions and dependencies involved with the who and what on a project. The RACI matrix is useful for communicating across the organization when a project needs support. This can be very useful in matrixed organizations and reduce the overall time required to get resources.

RACI MatrixAn example of a RACI Matrix will help show the value. Here is a sample matrix that will use SharePoint. From this visual,  you can quickly determine who does what.

On this sample, you can see the project manager is accountable for almost everything. Additionally, you can see what each person on the team owns and will drive to completion. A subtle point here in that it also indicates what tasks each person should plan, be involved with for, or otherwise be aware of. From my experience, it also visually emphasizes teamwork and that a team effort is required to deliver the project. Note – the astute among you will notice that the example matrixes shown in this post are transposed. However they are oriented, the concept remains the same.

Comments invited on this tool in project management, ITIL or Six Sigma.

SMART Requirements July 9, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , ,
add a comment

I’ve been ruminating lately on the interplay of the following : assumptions, requirements and expectations. Whenever we interact, being a good listener and confirming what you heard are key to meaningful conversations. Segue to a snippet of dialogue from a favorite movie scene :
Man: “You’d better tell the Captain we’ve got to land as soon as we can. This woman must be taken to a hospital.”
Woman: “A hospital? What is it?”
Man: “It’s a big building with doctors and patients, but that’s not important right now.”

smartWhich reminded me of SMART*. A quick search led me to this blog which captures what I agree with on the having clear, defined expectations and the big ‘R’ word, requirements. It should not always fall to the project manager to sort this out of course. Sponsors and customers can be SMART. Wouldn’t that be nice? Which implies process and management styles – a topic for a future post.

*Common definition for SMART: Specific, Measurable, Actionable, Reasonable and Timed

How often are your projects SMART? If you asked for that as a requirement, what are your expectations for a response?

The Practical Project Manager

In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.

Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer…

View original post 1,658 more words

Ramblings about PMOs May 15, 2014

Posted by Edwin Ritter in Project Management.
Tags: , ,
3 comments

In my recent past, I heard our company management question the value in having a PMO. My understanding has always been that the primary reason a PMO exists is to define and maintain standards for project management. PMO is the acronym for Project Management Office. The bottom line result in using a consistent set of standards and practices maintained by a PMO is reduced costs in delivering projects to the customer (internal or external). Often in establishing a PMO, the templates and supporting processes are tailored to suite the organization and culture. When done right, the value is easily understood and there is a proper balance of process, overhead and execution.

pmoroles

I recently came across two appropriate  graphics from another blog that show what a PMO does. A shout out here to the Project Management Files blog here as the source for these images. I submit they quickly depict visually what the PMO can do. The image above shows the PMO transitions involved with the queue of potential projects, active projects and the archive of closed/completed projects. There are many tools to manage these transitions. How to evaluate a candidate project for approval is related to ITIL and of course, the management style. Also related to my previous post on being data driven.

portfolio program project

Another value the PMO provides is with managing the project portfolio and programs. From the same blog, this 2nd image shows how the portfolio, program and projects are distinct. Notice how as a planning tool, this portfolio view can easily be used as a roadmap. In terms of communications with a project team, a PM group or PMO stakeholders, having this overview of projects and interplay among program and the overall portfolio should not be underestimated. It is a much easier discussion to adjust timing of any project and then sort out the impact later. Together these two images provide a great educational tool to ensure everyone understands how projects will be deployed/evaluated/resourced.

Im my journey as a project manager, I have contributed to PMO standards and practices in several organizations. I appreciate the value in having those standards and consistent process to drive projects. The value comes in everyone knowing (and, agreeing on) what is being worked on across the organization and when it will be delivered.

At least one management team did not see that. They had but to ask to find out.

What does your organization use? What is used to manage projects? Does it have a PMO?

Impact of Project Communications February 25, 2014

Posted by Edwin Ritter in Project Management.
Tags: , , , , , , ,
1 comment so far

One of the most important skills I find in project management is being able to communicate. It may sound simple and a bit obvious and yet can be a hard lesson learned for project managers.  My experience has shown that having the ability to hear and,  just as important, be heard, can make or break a project. The format and style used in those communications can be formal or informal, relative to the culture and management style of the organization. Regardless, that ability to indicate progress or raise issues quickly and get feedback keeps a project on track and moving forward.

Feedback-LoopIn fact, I prefer having a closed loop in communicating. I have found that the feedback loop is key to keeping everyone on the same page about a project. This works not only during execution but also for change management. Without feedback, you may not meet the needs of the client and/or stakeholders. That is a waste of both time and money for them and you. That can easily be avoided working in a closed loop with feedback.

The Project Management Institute lists 5 skills each project manager should have to be successful. The list includes the following traits:

  1. Listen to both what is said and what is not said.
  2. Build relationships with everyone involved in the project and across, up and down the organization.
  3. Set clear priorities with the team and obtain that list from the stakeholders.
  4. Collaborate with everyone as none of us is as smart as all of us.
  5. Convey the mission and project impact to it.

I agree with this list and also expect that stakeholders have similar skills. Their ability to listen and provide clear direction is a key success factor on every project.

Without feedback, how would you know you when you successfully deliver a project?

Ramblings on web design process October 26, 2013

Posted by Edwin Ritter in E-Commerce, Project Management.
Tags: , , , , ,
add a comment

You know the phrase “It’s great when a plan comes together”? It strikes me as odd that we are surprised when the results of planning using a consistent process yields what we expect. That’s the purpose of a plan. Perhaps from experience we know that a plan and process don’t always match reality.

I found this infographic a while ago and posted it to Slideshare (shameless unintended plug). It is a useful visual to show the end to end process in plan, design and build phases of a website. From project to project, the actual timing can vary widely from what is shown. Factors such as scope and complexity, cost and resources will drive the actual durations. This graphic is useful in guiding the conversation with teams and clients alike. During status updates, it’s useful to ensure everyone understand which phase we are in. It helps set expectations and also show what’s next.

However, I’ve found that some phases are not optimized, like reviews and approvals. Reviews and approvals tend to take much more time than we expect. That makes project management interesting. How do you account for extended review cycles without impacting the delivery date? What makes it more fun is some client adding new features during the reviews. Call it scope creep. I’m sure they realize it will change the end date.  Simple math, really. More features = more time.

Following the plan takes rigor and discipline. Flexibility also helps when reality hits. Keep your plan together. Sorting out the impact to the plan and getting everyone to agree can be a daily task for project managers. I always preface updates to clients with the phrase “I don’t make the news, just report it.”  So, don’t be surprised. Expect the results you plan on.

It is great when a plan comes together. That’s why you use a process to make it happen.

Ruminations on Software Development Life Cycle (aka, SDLC) July 18, 2013

Posted by Edwin Ritter in Trends.
Tags: , , , , , , , , , , , ,
4 comments

In my last post, I covered my recent efforts at software programming after a self-imposed hiatus. As a follow up, I wanted to talk about the development cycle. More specifically, the software development lifecycle. The most traditional development method is the Waterfall method. As it’s name implies, the lifecycle flows across phases with the result being a finished product that is tested to satisfy design requirements.

sdlc_lifecycleDeployment methods I have used include Waterfall and Agile among others and hybrids of these. As shown in the image, there is a feedback loop with testing that can introduce new/revised requirements. That starts the cycle over again, from the beginning. From my experience, there are two phases that seem to get short shrift. One or both of these typically get compressed due to project constraints and are sacrificed in order to stay on schedule. Those phases include Design and Test. What I have also found is that if you accelerate either of those, the project will reap a short term benefit. But, ultimately the project will not stay on track. Instead,  the project will re-visit one or both phases, which causes waste, and any gains in time expected are then not delivered.

As a programmer, I admit I have squeezed several phases. My advice – whatever process you employ, don’t cheat it. Having a solid design ensures requirements are addressed and adequate testing provides confidence for success at launch. Whatever method you use, adhere to the diligence in each phase and then keep progressing forward. Each phase should be  sized according to the project goal. Changes to existing code base can be minimal and have little design impact. Great! Testing should then focus on regression impact to ensure everything is working with new changes integrated cleanly.

Does your mileage match mine? Comments invited!

Ramblings on Work Units August 12, 2012

Posted by Edwin Ritter in career, Trends.
Tags: , , , , , , ,
add a comment

I am fortunate that in my career I have worked at both the management and individual contributor levels. The positions I held have mostly been technical roles in  IT, Marketing and of course, Project Management Office (PMO). I have also worked at multiple companies and while there are consistencies, I have also encountered unique processes, tools and ways to measure units of work.

Those development and management jobs I have had require many skills. Common in this non-inclusive list are : effective communication, organization, detail focus, decision making, analysis (technical and business) and the ability work work well with anyone in the company. The way a unit of work is measured in these positions will vary, but at a fundamental level, work is work. Which bring me to the focus of this post.

Job descriptions provide some insight on the unit of work involved. I find it amusing the lengths some companies go to when posting for open positions. There should be more consistency in job functions and the work required within those roles. By that I mean the skills required should be equivalent and measured against a consistent standard. I realize they should be; some would say they are. I do not agree.

In some job descriptions, the unit of work can easily be discerned. Project Managers manage projects. Developers write code. QA ensures it works as designed. Each of those can be measured as a unit of work. The variance is in what tools and processes companies use to measure (assuming they do). Too often, the job description contains fluff about the company, what a difference you can make, etc..

Next time you read a job description, look for the terms that describe the essential unit of work. If you don’t find it, I submit it is poorly written.

I’m interested in how you measure your work. Do you measure your productivity with units of work? Have you used them to generate estimates? For yourself? For your team?

Ramblings on Cycles and Phases August 30, 2011

Posted by Edwin Ritter in Project Management, Trends.
Tags: , , ,
2 comments

In a recent book review I read, the author proposed that the Big Bang might be cyclical. The premise is that given enough time, everything in the universe starts over again. Man, that is like, totally cosmic. That is a long cycle for sure. We have some time before the cycle is complete and begins again. Until then, the universe will keep expanding.

Having a repeatable cycle is also beneficial on a smaller scale. Like our daily routine. We humans are creatures of habit.  Typically, we do not like change. This is especially true in business – we like having a predictable and repeatable process. There is the challenge to keep it from boring rote execution. Management types appreciate working with knowns as opposed to unknowns. Having that consistent process cycle is a good thing.

When managing projects, I like having distinct phases (i.e. – discovery, planning, execution, etc.). Managing phases and cycles across multiple projects can be challenging yet also very rewarding. I enjoy the interesting challenge of having a cycle of multiple projects in different phases. Those situations keep you focused!

I think we are entering a business cycle where things will accelerate. Companies that are properly positioned with resources and good business processes can take advantage with increased sales, market share and ultimately, profit.

What phase is your company currently in? When the boom cycle starts again, will you be ready?