Skip to main content

Tag: Planning

Control Projects, Not People

Written by Andrea Brockmeier on . Posted in Articles. 2 Comments on Control Projects, Not People

Controlling projects is a good thing. Controlling people is not. What does it mean to control projects, not people, and when have you crossed the threshold from controlling the project to micromanaging the people?

When you start telling people how to do their jobs instead of focusing on the results they create is usually an indication that you have stepped beyond the bounds of project control and into the realm of people control.

Some team members are quite adept at complicating this tidy distinction. What about, for example, the team member who tells you they will get the work done on time but sees no need to share details regarding the steps involved or how they’re going to get it done?

Even if it’s someone you have previously worked with and have every confidence that they’ll meet their deadline, it’s conceivable that you need more information about what’s involved in accomplishing the work. Perhaps for reporting or tracking purposes, for example, you may need to know about the steps involved or milestones in getting to their end result.

How can you ask for details that may not, in fact, be necessary to the person doing the work without being perceived as trying to micromanage? The most important thing is make sure the team member understands why you need the lower-level information. In the absence of an example or clear explanation of reporting or tracking requirements, many people are going to infer a lack of trust in a request for more detail than what they’re initially interested in providing.

The following three ideas can also help a project manager engage a resistant team member in providing more detail about their project work:

  1. Suggest breaking down the work into smaller chunks to make it easier to share the work load or include others in accomplishing the result. If they decompose the work into smaller level activities or tasks, perhaps there are things that could be done by others.
  2. Present it as an opportunity to teach others. If the team member can break down what it is they do to get their work done, it is easier to show and train others how to do it. Even if it’s not entirely repeatable, knowledge transfer requires some level of decomposition, and teaching others is usually an appealing personal development opportunity as well as valuable to the team and organization overall.
  3. Consider the information in the context of risk. Breaking down the work presents opportunities for identifying risks that might otherwise be missed. Engaging the team member in that discussion may yield ideas that even they hadn’t considered in terms of possible threats.

When project managers have a need for more details than team members are initially willing to provide regarding the work they do, these perspectives can help soften resistance by showing team members how they can contribute to something rather than making them feel like they are being needlessly imposed upon or, worse, not trusted.

So go ahead ask: “Tell me more about what’s involved in getting that done.”

Don’t forget to leave your comments below.

Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning.  Andrea is a PMP® as well as Certified ScrumMaster.  She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

10 Key Success Factors for Application Implementation Projects

Written by Brenda Hallman on . Posted in Articles. 88 Comments on 10 Key Success Factors for Application Implementation Projects

There are many factors in an application implementation-related project that over time have proved to be key contributors to the success of such projects.  This includes items that may seem obvious, such as solid testing, communication, and involvement by key staff members, but these are often under utilized in favor of saving time.  When projects skimp on these key items, it is likely to result in:

  • delays in meeting project dates,
  • disagreements on what the project is expected to deliver,
  • difficulty solving issues,
  • confusion on direction, work requirements, and status of the project,
  • lack of buy-in from team members and the end users,
  • additional stress and demands on the time of team members and end users, particularly near the end of the project,
  • less satisfaction from the client on the final delivered product.

{loadmodule mod_custom,ad 300×100 Large mobile}

Many types of documents, templates, tools, and strategies exist for managing a project.  This article will focus on 10 items that represent supported concepts in the project management industry and should, at minimum, be utilized for all significant application implementation projects. 

Related Article: A Project Manager’s Guide to User Experience

1. Solid contract with software provider

A verbal agreement won’t cut the paper it’s written on. Get it in writing! If a contract is already completed and these items have not been included, you should work with your vendor to reach agreement on these terms.  Additionally, you should work with your organization to see that these items are included in future contracts. 

The components that you will want to have well defined are:

1. a payment schedule,

2. outline system performance criteria,

3. penalties related to performance issues and delivery delays,

4. documentation requirements,

5. training, which is provided,

6. inclusion of a test system, and possibly a training system,

7. issue resolution/turnaround time/escalation policy,

8. and vendor support during and after the application live event.

Having these items defined contractually is an assist to the project manager.  It will provide you with agreed-upon criteria allowing you the leverage to hold your vendors accountable to their deliverables. 

2. Involvement by key staff and resources

The organizational structure of those involved in the project is a significant indication of the success of a project and is one of the first things you want to have in place to start the project.

Make sure to have a:

  • Project Sponsor. 

This person should be a senior manager head of the Steering Committee.  They will be the source who authorizes the project, ultimately ‘owns’ the project, and sources the funding for the project. They would not and should not be a member of the project team. 

  • Leadership Committee. 

This leadership committee is responsible for following the status of the project, representing the project to their peers and senior management, and assuring all of the appropriate parties are involved.  This group will make any decisions that the team cannot determine, they will assist rectifying business issues and with escalation of problems including to vendors or internal staffing. Use these people!  They are there for you.

  •  Project Team. 

These are the folks that are performing the work for the project. You may have several teams, or workgroups, with different focuses.   

  • Project Manager. 

Hey!  This is probably you! The Project Manager is responsible for overseeing that the work is getting completed as expected on schedule.  They manage any deviation from the scope or schedule to get the project back on track.  They are generally responsible for planning and often own and complete the project documents (such as the scope, staffing plan).

Additionally, consider the following while staffing the project team:

  • Be certain to include individuals who know the business.  If there are different aspects of the business involved in the project, include a representative from each of these areas.  These individuals will often serve the most benefit as project team members who are active in identifying processes, business needs, and performing testing and training. 
  • Consider a ‘superuser’ strategy.  This works well where individuals are identified early on in the project to serve as business/application experts.  They may be those who perform testing and training as well as first line support for end users.  These users can often serve as project team members.
  • A Project Staffing Plan should be completed to include the names of the individuals involved, the committee or teams that they are serving on, and the roles and responsibilities of those individuals and teams.  All team members, and their managers, should approve this plan so there is agreement on the expectations. 

3. Plan how the project will be managed

Create and share a Project Management Plan that will document how the project will be managed.  This should be agreed upon with the resources and management.

  • Document how changes will be handled, especially those that impact the scope, dates, budget, or resources.
  • Document how issues will be managed and escalated.
  • State how the schedule will be managed.
  • Include all methods of communications that will be used for the project.           
  • Once you review this with the team, you will likely be the sole audience for it.  Really, it’s not that entertaining and you shouldn’t expect others to be interested in it.  However, you will utilize the content to guide how various aspects of the project are to be managed and you may also refer to it if a deviation occurs where you need to reference the agreed-upon terms.

4. Define and agree upon the project scope

Write a project Scope, state what is and what is not included in the project. 

  • Document deliverables and assumptions.
  • Refer to any requirements that were gathered.  If no requirements were gathered, meet with stakeholders across the board to determine their requirements so that expectations can be documented and agreed upon.
  • Include Milestones, which are significant events, with their due dates.  Remember that “TBD” is not a date!
  • All project team members should understand the scope.
  • It is important to get formal approval from the Steering Committee on the scope before the project execution phases begin. 

5. Development and management of a schedule

A Schedule is the central tool to managing a project’s activities and keeping on track.

  • Develop a schedule that documents the tasks that need to be done to complete all of the deliverables outlined in the scope. 
  • Be sure to include dependencies, but not the work associated with those dependencies, on items that are outside the scope of the project.
  • Assign names and due dates to each task.  Does that seem obvious?  While it is probably obvious, it is not always done.  Oh, “TBD” is not a person either!
  • Items that risk a delay should be done as early as possible.  This may include such things as ordering hardware or scheduling training.
  • Highlight tasks that are milestones from the Scope. This will allow better tracking and reporting of those milestones.
  • Note items that are on the critical path (these are tasks that if delayed will delay the rest of the project).  Special attention should be paid to these tasks to keep the project on time.

6. Management of an Issues List

Having one central repository to log issues is invaluable. 

  • Each issue should include a clear description, name of who is assigned to own/resolve the issue, a due date, status, and priority.  If an issue is being resolved by someone who is not on the team, it should be assigned to a team member who is responsible for tracking the issue.  Another note, “ASAP” is not a date!  Your ‘soon’ and someone else’s ‘soon’ can be two entirely different times!
  • “High” priority should be reserved for those issues that, if not resolved, could impact the stability of the application, the integrity of the data, or completion dates of critical tasks and events. 
  • Track issues actively (daily or weekly).  Include new ones as soon as they arise.  Log updates to each issue as they become known. 
  • Document issues even if they are likely to be easily solved.  Those tend to be the ones that get away and should not be ignored.
  • Share the issues list with the entire project team; get updates regularly from the owners of the issues as well as team members who may have items to add.

7. Solid Testing

Testing is critical to understand how the application will work in the installed environment, if it performs according to expectations, and to identify any problems with the software or processes so they are addressed prior to the live event.

  • Document what type of testing must be done (i.e., database conversion, data flows, user front end, business flow).  Include who will be involved in testing and how it will be performed. 
  • Write Test Scripts that detail all scenarios that could occur.  Business end users should be involved in this as they are most likely to understand all aspects of their business. 
  • Test items that are standard operations as well as those items that occur infrequently.
  • Conduct user testing with staff members who are familiar with the business for which the application is designed.  They should be validating the application for their business.
  • Allow time in the schedule to retest anything that did not work initially.  If any changes are made to software or setup, run through most tests again to assure there is no negative impact in other areas.
  • Determine security access, setup, and test user accounts prior to live.

 8. Training Program

Proper training is essential to assure that end users are prepared to use the application.

  • Identify all users early on in the project; this will help to confirm all possible scenarios are covered and all users are part of the project communication.
  • Training will be optimized, and sessions better received, if individuals who will have similar use of the application are trained together. Also, if there are users who are not familiar with computer systems, consider holding a general knowledge training first.
  • If the possibility exists, allow the users to have access to the test or training system before the live so they can practice.  Consider providing practice scenarios for this occasion.
  • Create a Tip Sheet that is easy to read and highlights the top items a user would need to know.  This can be useful for the live as well.

9. Preparation for Live Event

A review of all deliverables and tasks should occur weeks before the system is ready for production use. 

  • Anyone involved in the project should verify that all tasks are completed, or will be completed as scheduled, for the live event. 
  • Issues should be scrutinized at this time so a decision can be made regarding their potential impact to the live.
  • Assign staff who have a good understanding of the application and business to assist users during the first days of production use.  Establish a central call number that is staffed with individuals who can track, solve, or escalate issues.

10. Communication

Communication is one of the key items recognized as leading to a successful project.  It should also be noted that in projects experiencing problems, communication is often reported as lacking.  So last, but certainly not least, are tips to improve this valuable activity.

  • Keep committees and teams informed.  The Steering Committee should be meeting at least once a month. The agenda should include a review of an up-to-date status report and focus on any issues or concerns with dates or deliverables. This committee should not be concerned with the work outlined in the schedule, but rather the higher-level milestones.  The same holds true with issues.  Only review high-priority issues that may have a negative impact on the project and not the entire issues list.
  • Team meetings should occur weekly or as needed.  Even a short conference call meeting can be effective to get everyone together. Those involved will have an opportunity to state something that may otherwise be overlooked. Status on the work being completed can be shared with all team members to assure everyone is in line with what is expected.
  • Monthly or weekly Status Reports should be completed and shared with all involved individuals.  The status report should include: status of milestones, recent work completed, what work is to occur next, high-priority issues, and changes to budget, scope, schedule, or resources.  This should not be a detailed account of activities but rather a summary.
  • Users should be informed of the progress of the project as it evolves.  Try to present them with demonstrations of the application in advance.  Distributing emails or newsletters are a good way to get information out and often receives a positive response.  End users do not need to know about problems, but the more they are involved with the status of the project, the more they will accept the change.
  • Remember that communication is vital to the success of a project.  It allows for establishing expectations and keeping everyone informed.  Only provide recipients with information they require and do not burden them with excessive details.  Different audiences may require different formats or content.        

Consider the above items when approaching your next project.  Although this article describes some instances specific to application-related projects, most strategies will be valuable to any project.

Don’t forget to leave your comments below.

Brenda Hallman has over 15 years of experience in project management, most recently in the Project Management Office at Main Line Health where she is responsible for standards, tools, mentoring, education, and program development for project management staff.  Ms. Hallman has a Bachelors of Science Degree in Computer Science and Mathematics from Edinboro University, a Masters Degree in Business from Penn State University, and a Masters Certification in Project Management from Villanova University.  She has worked in the information services arena initially in software development and later in project management.  She is PMP certified.

Managing Schedule Flaws Using Agile Methods

Written by Brian Button on . Posted in Articles. 4 Comments on Managing Schedule Flaws Using Agile Methods

Aug3FeatSoftware projects rarely come in both on time and on budget, leading to dissatisfied end users. DeMarco and Lister, authors of Waltzing with Bears: Managing Risk on Software Projects, discuss five different risks associated with software project management, including schedule flaws as one of them.

In this article, we’ll discuss several symptoms and causes of schedule flaws, present metrics and diagrams that can be used to track your team’s progress against its schedule, and describe Agile ways to address these risks.

CAUSES

Schedule flaws can be caused by the unpredictability of the environment around a project or by the inherent difficulty in predicting the time significant pieces of software will take to implement.

Estimation difficulties are just a fact. We rarely create the same systems twice, so each new project is truly new. Each has their own problems, solutions, and complexities. No software plan survives its first contact with the customer, leading to a situation where your plan needs to evolve to match changing reality. This is the risk that we’ll focus on below.

SYMPTOMS

Teams that suffer from schedule flaws often exhibit one or more of the following five symptoms:

1. Frequent change requests from customers and stakeholders
Customers and stakeholders learn more about the system being built as it takes shape. Based on their new knowledge, stakeholders often change their minds about existing requirements or adding new requirements.

2. Unreliable estimates
Every interesting piece of software that gets built is inherently something new. Because of this, the time to build individual pieces is difficult to estimate accurately.

3. Large amount of “off the books” work
All teams have “extra” work to do that is never written down, be it testing, documentation, or just finishing the “edge cases” of features. This work has to happen, but it appears on no one’s schedule.

4. Uncertain quality
Inadequate or late testing leaves the quality of the system in doubt, allowing defects to be found in final testing. Since these defects are unknown until the last round of testing, their effect on the schedule is unknown.

5. Matrixed team members
Team members that are shared among multiple teams can become bottlenecks. Waiting for them to become available can cause delays in deliverables.

METRICS

It’s important to have a good set of historical metrics to understand the effects the above causes of schedule flaws have on your project. The most basic metrics used to track a project’s progress and to illustrate schedule flaws are two variations of burn charts. The first, a burndown chart, graphs work completed versus time, sometimes with both actual and planned work/timelines shown. A burnup chart shows the same information, additionally showing work added to a project over time. A project is on-track as long as the actual progress and planned progress shown on either type of chart match. A solid metric describing progress against your desired delivery date is the most critical measurement for a project to keep, since it is the leading indicator of whether you have a problem.

In Figure 1, Example Burn Down Chart, we can see a project that spent several weeks basically tracking the ideal curve down their burndown chart. Sudden, though, the project went off-track. A large amount of work was added to the release, as can be inferred by the upwards slope of the burndown line. Scope had to be cut or time added to bring the project in successfully.

Brian1

In Figure 2, Example Burn Up Chart, the total height of any bar represents the total amount of work present in the project. The area in green represents work completed and the area in red shows work left to do. The total amount of work in scope varies as the total height changes. Here, you can see that work is being added as quickly as it is being finished, resulting in a finish line that is constantly moving to the right.

Brian2

These two graphs show the same backlog for the same project, but illustrate the different information available from each graph.

METRICS TO UNDERSTAND CAUSES

Once it is determined that the project is not keeping to its schedule, more investigation must be done to determine why that is. Below are several metrics that can be used to learn about underlying causes of schedule flaws.

1. Changing Capacity
Teams that do not have a stable amount of working hours can see their productivity rise and fall as their capacity changes. Measuring the number of available hours across the entire team will provide insight as to whether this is the cause of the schedule flaw. If it is, you’ll see velocity vary directly with capacity.

Brian3

2. Poor Estimation Accuracy
The most important part of looking at estimation accuracy is identifying stories that are outliers from the main body of the estimates and to understand what made them off by so much. When the outliers are found, some level of root cause analysis can be done to understand if there was a special reason for that variance or if there is something systemically wrong with the estimates that made a group of them drastically wrong.

For example, on a recent project I managed, we tracked estimates versus actuals. Every story was estimated in “points,” where a single point corresponded to a half-day of work. When graphed, we saw how rapidly the distribution of results changed as the estimated size of each story increased.

In Figure 4, Estimates versus Actuals for 1 Point Stories, we can see a graph of our results. The X-axis represents the actual number of hours taken by a story, while the Y-axis shows how many stories had the same actual duration. The majority of stories were six hours or fewer, with many of them being shorter than four hours — we didn’t have fractional points, so one point was a low as we could go. There were a few outliers, though, and we talked about the special causes of them. In some cases, there were defects or poorly written code in the inherited codebase; in others the requirements were unclear early and grew as they were better understood.

Brian4

As the size of the story estimates increased, even to two points, the quality of the estimates began to drop. In Figure 5, Estimates versus Actuals for 2 Point Stories, you can see a larger spread of actuals resulting from the same types of issues in the first case, with misunderstood requirements playing a larger part in the inaccuracies as estimates grew.

Brian5

3. Uncertain Quality and “Off the Books” Work
On teams with whom I’ve been associated, these two causes are known by everyone on the team but acknowledged by no one. The best way to understand the effects of these two flaws is for a manager to work closely enough with the team to feel the undercurrent of tension that people are surely experiencing. Faced with this undercurrent, they must start conversations about quality and completeness and readiness. The longer the team waits to have these conversations, the more unpleasant the surprise at the project’s end.

AGILE PLANNING & ROADMAPS 

Each of these causes of schedule flaws represent risks to a project. Agile teams manage this risk by changing the role and method of planning versus more traditionally run projects.

Agile teams plan differently. They absolutely have a plan and a schedule, but the plan is encouraged to change over time as learning happens. Planning becomes a commonplace activity, performed at different levels and at different rhythms throughout a project. These different levels of planning serve to address each of the issues described above in specific ways.

At the highest levels, Agile teams plan to deliver capabilities to customers at some agreed-upon schedule. These capabilities are loosely defined to leave as much wiggle room as possible while giving as complete a description of the feature as possible. This wiggle room sounds absurd on the surface, but it is actually a key ingredient of what makes this style of planning so successful.

The output of this planning is a roadmap of capabilities that will be delivered at specified times in the future, with some amount of detail about what each capability will provide. That should be enough for long-range planning, marketing, and sales. They have a rough roadmap and a near certain guarantee of delivery.

By keeping this long-range planning at a very high level, people are free to make changes in the plan at this point, whether from changing market forces or in reaction to a schedule flaw, with little cost and with little risk. This level of planning happens several times a year.

PLANNING & EXECUTION

One level down from roadmap/portfolio level planning is Release Planning. This is when teams solidify the features they are going to deliver typically 4–12 weeks out. Capabilities from the roadmap are selected and broken down into smaller, more understandable pieces, called epics. Epics represent coherent, releasable features in an application that are more defined than larger capabilities but still larger than what can be implemented. The epics selected first tend to be the ones that provide the greatest value to business stakeholders, risk reduction, or learning for an organization. Lower-valued features are pushed later in the project schedule, or perhaps fall off completely if their value never becomes high enough to justify the cost of developing them.

The epics are estimated by the practitioners who are going to implement them, and are prioritized according to their importance to the release. This level of planning happens once per release: 4–12 times a year.

The most frequent form of planning, iteration planning, happens once every week or two and is where the rubber meets the road. A small number of epics are brought to the team, where they are broken into “user stories,” small bits of functionality that provide some portion of the epics’ features.

During iteration planning, the team discusses the low-level business details of the work and builds a plan for how they are going to implement this set of user stories. Each story is defined as concretely as possible, including a set of acceptance criteria that detail what it means for that story to be done. At this point, these finely grained units of work are generally a day or less of work. As described above, smaller stories are estimated more accurately.

As part of the capacity planning used during iteration planning, historical values for the capacity of the team are tracked and used to limit the amount of work promised for the one- to two-week time box. This regular rhythm of planning, committing, executing, and delivering gives the project a heartbeat that allows its progress to be measured and tracked.

The final execution stage is where quality is monitored and created every day. Quality is never uncertain on a team like this. Each move that a team member makes is done with an eye on producing quality. There are automated tests around security, load, scalability, and performance. Most tests are run dozens of times a day and at least once per night. The system is continuously built, deployed, and tested.

Obviously, there is effort expended to reach these quality levels, but the benefit is that a team can be ready to ship code at any time. Every feature that is done is coded, tested at the feature and system level, all needed documentation is written, and it is ready to go. This lets progress through the project be tracked in terms of completed value, and allows for early and incremental delivery of working functionality.

By focusing on the agile practices and metrics detailed in this article, teams can identify and manage the risks that cause schedule flaws. These metrics give visibility to the risks, while the practices give teams tools to manage them. Between the combination of the two, teams can deliver great value to their stakeholders quickly, effectively, and with high quality.

Don’t forget to leave your comments below.

Brian Button is the VP of Engineering and Director of Agile Methods at Asynchrony Solutions, Inc. a leader in Agile software development. Brian instituted the Asynchrony Center of Excellence, leading a group of agile trainers and mentors that train, innovate, and evangelize agile to internal staff and project teams at outside corporations.


How to Determine PMO’s Identity

Written by Abid Mustafa on . Posted in Articles. 6 Comments on How to Determine PMO’s Identity

The establishment of PMOs is a daunting task that requires great wisdom and perseverance. What is of paramount importance for the PMO’s success and longevity is to make the management of executive interests an intrinsic feature of PMOs, while weaving them into the very fabric of the project organization. This implies that the design and construction of the PMO must happen organically, i.e., the structure of the PMO cannot be imposed or rushed, but must develop naturally. However, in practice, there is a strong impulse to simply ‘cut & paste’ PMO solutions. This is often done without a correct understanding of the problems affecting projects and possessing an inaccurate assessment of executive views on role of the PMO. In most cases, PMOs are established based on an arbitrary executive instruction. The purpose of this article is to explore techniques on how to analyze and assess what executives really want from PMOs.

The most important facet in the establishment of the PMO is to clearly recognize what role the executives want the PMO to play. Some conventional approaches rely on questionnaires that ask executives to respond to pre-defined roles for PMOs, i.e., ‘Would you like the PMO to play a supporting or directing role in project management?’ Views captured in this manner are then debated and the majority view is taken to determine the role of the PMO (although sometimes the CEO’s decision is invoked to expedite a conclusion). By taking this approach, discussions are not very productive as they are framed within an artificial and somewhat imposed context that is often disconnected from the current problems of the company. The identity of the PMO that is synthesized from such a process is usually prone to vagueness and diffidence.

To avoid such outcomes, it is important to understand the background of executives and their past interactions with PMOs. The two matrices presented below enable one to accurately identify PMO competencies, map their maturity and accommodate the interests of the CxOs. Figure 1-1 is a simple matrix that highlights the exposure of executives to PMO functions.

Abid11

Figure 1-1 Past Executive interactions with PMOs denoted by ‘x’

In this particular example, the overwhelming PMO experience for many of the executives includes exposure to executive meetings, followed by launch office and business processes activities. Important inferences can be drawn from this information. Both the CCO and COO come from a program delivery background, whereas the CPO (Chief Project Officer) has more of a project/program support background. Hence, this could be a potential source of conflict between executive management. Another point of contention might be the drafting and monitoring of business processes. Utilizing matrices such as this highlight the disposition of CxOs toward PMO functions and can help mitigate sources of conflict.

However, to define a PMO’s identity, it is not sufficient to scrutinize executive experiences with past PMOs. Instead, the CxOs must be encouraged to think about the role of the PMO within the context of their present work environment, which must be related to the execution of initiatives. A second matrix described in figure 1.2 below can be used to illustrate this point.

Abid1

Figure 1-2 Present-day executive requirements for PMO (denoted by ‘x’)

In this example, few executives see the need to align initiatives with the company’s strategy or manage a portfolio; even though this is regarded as vital for ‘doing the right things’ and is normally considered as industry best practice. Rather, the focus for the majority is on program delivery, monitoring operational KPIs and task force work. Hence, a clear conflict of interest awaits the CPO with his or her peers. Oddly enough, there is also no mention of the PMO performing one of its core activities that is the standardization of project methodology, tools and standards, i.e., ‘doing things right.’ Again, a matrix such as this can be used to identify what CxOs would like their PMO to do. It is recommended to use such a matrix after the CxOs have either struggled to deliver a particular initiative (one that involves all of them), or they have repeatedly encountered project/program failure.

So here’s the challenge: how does one make the CxOs cognizant about the importance of PMO’s core competencies, while at the same time, not alienate one’s personal dispositions? This conundrum cannot be resolved by simply taking a majority decision on what the PMO should or should not be doing, as this will prompt some executives to merely pay lip service and withhold their wholehearted support for the more important initiatives.

While there is no one solution, every company is different and the interplay of CxOs varies from organization to organization. Therefore, it is important for the one charged with the responsibility of establishing the PMO to do their utmost to define the PMO competencies and chart their respective evolution, in the best interest of the company. This means that all the interests of the CxOs—no matter how miniscule—must be accommodated. Furthermore, many competencies take a great deal of time to develop and mature. Consequently, the CxOs have to be informed and persuaded about the availability of such competencies. For instance, in figure 1.2, portfolio management, or program delivery, cannot be instigated unless the PMO possesses a sound project methodology. CxOs must be won over on the value of this truth, as opposed to just being told.

In summary, to ‘cut and paste’ PMO solutions, or to convince CxOs about the implementation of best practice PMO methodologies, is a recipe for failure and extremely expensive! Instead, a great deal of time and effort needs to be invested to cultivate the right PMO identity, with continued executive support. Unfortunately, this is an arduous journey and there are no shortcuts on the way.

Don’t forget to leave your comments below.

Abid Mustafa is a seasoned professional with 18 years’ experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.

A Surefire Plan for Improved Project Results and Increased Maturity

Written by Curt Finch on . Posted in Articles. 5 Comments on A Surefire Plan for Improved Project Results and Increased Maturity

Many of the clients we work with are a “PMO of one.” Usually this person has been brought in to establish common processes and procedures around planning, managing and executing projects. Most often, there is a broad spectrum of project work being performed by varied project teams within the organization, including a range of maturity levels spanning from no established, repeatable processes to very formalized and documented processes.

According to the Project Management Institute, “Companies with greater maturity should expect to see tangible benefits that include better-performing project portfolios, efficiencies that come with better resource allocation, and increased process stability and repeatability.” [i] On the other hand, companies that are less mature tend to be reactionary, trying to dodge problems as they come rather than strategically planning and executing projects. Often, these companies have various groups working in their own silos, so there is no centralized view of resource availability or up-to-date project status. Project managers are consequently unable to prioritize projects or schedule them with accuracy. This can lead to lost opportunities and failed projects time and again. A new study on organizational maturity has confirmed the need for defined repeatable processes, finding that companies that use them have a much higher project success rate than those who do not. [ii]

So how can the “PMO of one” bring teams and processes together to get everyone on the same page, speaking the same language and doing things in similar ways? Here are some things to think about for establishing common project processes that can be adopted throughout the organization, providing better performance and tangible results.

Focus on the Critical Business Issue

There are a number of reasons why an organization would decide to unify its project management processes. It could be a response to client pressure, a desire for an additional competitive advantage, or part of the general evolution of the company. Other times, the lack of organizational maturity is leading to lost opportunities. Understanding the reason behind the shift will not only give you direction as to how you should approach it, but can also help project managers to find creative ways to address the issue.

Don’t just establish processes for the sake of establishing processes. Rather, let the fundamental issues you’re trying to address or avoid drive your direction. You might find, for example, that re-engineering your processes isn’t what you need at all. Perhaps providing increased transparency, visibility and collaboration around all of the projects across the organization better addresses the critical business issue.

Transparency, Visibility and Collaboration

Adding transparency, visibility and collaboration to your projects is integral to achieving better organizational performance. In a recent article, Gina Abudi recommends a central system or “portal” as a means to implement best practices and improve project results. [iii] This does not, however, have to be an overwhelming PPM solution. A simple, easy-to-use system to interface between time tracking, resource management and project scheduling allows businesses to retain processes that are currently in use while still benefiting from increased visibility to crucial data.

Software alone will not solve your critical business issue, but it can serve as a hub that provides one “pane of glass view” for all processes throughout the company. Keep in mind that it is necessary to choose the right system for your organization. A few key requirements are as follows:

  • Improved visibility of resource allocation, including project work, non-project work, vacation, etc.
  • Real-time status information across all projects with warning indicators and alerts
  • Integration between work requests, schedules, resource management, project roadmap and prioritization

A system that provides these benefits will enable project managers to focus scarce resources on the project that are most profitable. Project managers will also be able to keep track of which projects are on time and which ones are not, helping them to take immediate action as needed. Finally, they will no longer run the risk of scheduling a project under the assumption that certain resources will work on it, only to find out later that the resources are already allocated or will be out of the office.

Leverage What You Already Have

Just because you are trying to improve your organization does not mean that you should blow everything up and start over. Chances are you have processes currently in place that are working, and you should leverage these to get you to the next level. For example, you might find that despite the varied maturity levels, experience and background within your organization, most people are using Microsoft Project™ and Microsoft Excel™. A “rip and replace” approach where you force everyone to stop using these tools and start using a different system could have very adverse effects. Instead, you might look at how you can enhance and extend the tools, allowing people to keep the processes they are comfortable with while maximizing benefits and value.

Abudi agrees that you need to learn about what is currently being done throughout the organization before you try to make a change. Only then can you “discuss how standards may be developed organization-wide using a composition of processes already developed and being successfully implemented and filling in the gaps with new processes where needed.” In other words, rather than taking a standard like PMBOK® or PRINCE2® and forcing everyone to change their processes in order to uphold it, you can be a little more creative, retaining the things that work and improving or replacing the things that don’t.

Communication is also important because many employees will be resistant to change. They might be suspicious of your efforts to improve processes when they feel that the status quo is “good enough.” (Remember what Jim Collins wrote in his book, Good to Great: Why Some Companies Make the Leap and Other Don’t: “Good is the enemy of great.”) It is important to instill trust in these people so they understand that you are not looking to replace their current processes, but to improve and enhance them. Buy-in from your team is necessary in order to achieve success because they are the ones who will be helping you to reach your goals.

Better Project Results

Whatever you introduce is going to represent change, so it is important to understand how much change the organization and team can take and be mindful of that. There is no silver bullet, and something that worked for one company may not be a good fit for another. Only you will know what your needs are, what will and will not be adopted by the organization and how much time, money and energy the organization is willing to spend in comparison to the potential return.

Don’t rely solely on software either. Remember to integrate your processes and people, and manage them well. Your software solution will need to empower team members and facilitate their work.

By evaluating existing processes, organizations can replace the weaker ones and maintain the stronger ones for optimal success. Integrating these processes in such a way that everyone involved in a project is on the same page provides a way to learn from your failures as opposed to repeating them.

Don’t forget to leave your comments below.

Curt Finch is the CEO of Journyx. Since 1996, Journyx has remained committed to helping customers intelligently invest their time and resources to achieve per-person, per-project profitability. Curt earned a Bachelor of Science degree in Computer Science from Virginia Tech in 1987. As a software programmer fixing bugs for IBM in the early ‘90s, Curt Finch found that tracking the time it took to fix each bug revealed the per-bug profitability. Curt knew that this concept of using time-tracking data to determine project profitability was a winning idea and something that companies were not doing — yet…Curt created the world’s first Web-based timesheet application and the foundation for the current Journyx product offerings in 1997. Curt is an avid speaker and writer.