Skip to main content

Tag: Team

Enrolling the Reluctant Enterpriser

Written by Chris Vandersluis on . Posted in Articles. 12 Comments on Enrolling the Reluctant Enterpriser

reluctant1“Resistance is futile” was the battle cry of the evil Borg from Star Trek. Sometimes I’m sure there are PMOs that wish they could be as convincing to fellow colleagues who are resisting the deployment of enterprise project management and enterprise project management systems.

Getting the job of deploying an enterprise project management environment is not the best news for some people who have to complete that project within an organization where there may be a great deal of reluctance to change how projects are managed. Almost every week I’m in some meeting where a frustrated project manager is asking my advice on how they can convince the rest of the organization to embrace the new project management thinking.

Where Could We Go Wrong?

If you have just been assigned such a project, then the first thing to know is a few of the pitfalls.

I talk to a lot of people about project and timesheet systems, given the business I run, and one of the most common pitfalls has to do with enterprise project management software. “If you build it, they will come” is a common theme from those purchasing such software. I have met with numerous CIOs who have already concluded the purchase of a centralized project management tool and then call me to ask if I can “make it work” for them. I have to ask why they purchased the product. The answer inevitably is “Because it will help fix our project problems”. I have to ask if there is a design for how this particular tool will fix those problems, if there is a list of the ‘project problems’, if there is a process in place on which to base the use of the new tool. Even among very educated people, there is often an excessive dependence on technology to fix project management problems. A big pitfall then is thinking that the purchase and installation of some project software will do all the fixing for them.

A second significant pitfall is the reluctance of some executives to take a leadership role in the deployment of an enterprise project management environment. “Let’s manage by consensus,” goes the theory. Consensus is a wonderful thing if you don’t like conflict. A decision is left before a group of the rank and file. They won’t take a vote and choose based on the majority. They won’t choose a leader and do what the leader decides. They won’t have a leader imposed on them by a higher authority and do what that person directs. They will discuss, debate and eventually arrive at a decision that the whole group can agree on. There will be no conflict because everyone will have agreed. This may work well when picking a color for painting a room, but I can tell you from experience, it’s rarely successful when designing project management software. The most likely result is that the design will have accommodated every little request of each and every user to a point that the design is so complex as to be undeliverable or wildly beyond the budget. Or, that there is no consensus because of the investment members of the group have in avoiding change. Consensus is often a way for executives to avoid commitment. Turn the problem over to the employees and ask them to come up with a plan that everyone agrees on. It avoids conflict to be sure, but it also avoids creating a process that will make the entire organization more effective.

The last pitfall I’ll mention here is to avoid the Fifth Column. The Fifth Column is a term that comes from the Spanish Civil War circa 1936 when General Mola claimed to have a fifth column of military in Madrid while he was attacking with four columns from outside the city. We tend to use the term these days to refer to a clandestine element within our own organization that says it is our ally but, in fact, is working to subvert our objectives. Some executives tell me “our people will comply if I darned well tell them to,” when I ask how we will deal with support within the organization for an enterprise project management environment. But there are a lot of “Fifth Column” techniques for avoiding doing so. The most common, and for me, the most difficult to deal with is the middle manager who nods his or her head in agreement at every single meeting but then will take no action to support the project in any way.

A successful plan

Is it hopeless? It certainly is not. If you have the job of enrolling the reluctant enterprisers, there is a lot you can do. Here are some of the most successful techniques we’ve seen:

First make a plan. I know, I say that in some way in almost every article I write. The reason I say it so often is that it’s still the most common error I encounter. People often end up starting an enterprise project management project without a solid plan. They don’t “ready-aim-fire”. They “fire-fire-fire”. They are in action almost instantly, choosing an enterprise project management product, hiring skilled project managers, responding with action to management’s desire for more decision making tools. Then everything that happens subsequently is a reaction to not having had a plan in the first place. So, make a project plan. And, do all the things you’d normally do on any other project on this one too. That might mean creating a charter, getting a budget, having a schedule, choosing some milestones and so on.

Secondly, get some friends in high places. I’ve been around a number of EPM deployments lately where there is no management support at all. In one meeting, the vice-president who had started the initiative had deliberately avoided any meetings with the people involved because they didn’t want to interrupt the consensus building of the group. In another situation, the senior executive didn’t want to attend key decision-making meetings because they didn’t want to leave some employees who were not invited feeling like their fates were being decided in their absence.

It’s critical to have the support of some or all of senior management. If you don’t then the chances of success of the project drops quickly. Think of it like this. The project management process in most organizations will affect almost every part of the organization. Doesn’t it make sense that the senior management should play a significant role in redefining that process? The project management process for many organizations includes having an executive sponsor to shepherd the project through the senior management ranks. This project deserves the same.

Once you’ve got your plan, communicate it. Then do it again, and again, and again and again. Communicating how the plan is going to work, is working so far and how it worked yesterday will all go a long way towards enrolling those who might be worried about how the new enterprise project management environment will affect their jobs. Since EPM is always an evolving and adapting process, there should always be a little time reserved for communicating about it.

While some senior managers may believe they can come down and knock some heads together to get compliance, it is rarely successful. So, think in terms of more carrot and less stick. Instead of imposing big penalties on non-compliance, why not look to how you can improve the return on investment of each person who interacts with the new EPM environment. What can you give them that will make their life better and more effective?

Finally, try to have your plan deliver bite-sized pieces. Getting started small and gradually expanding the new process is inevitably more successful than trying to create a massive plan and delivering it all at once. There are a lot of reasons for this but one of the most important is that the very design you’re trying to create will be changed by implementing it. The needs and interests of the organization will evolve, and changing such a fundamental process might have it evolve significantly. If you’re deploying your new EPM system bit by bit then you can adapt each parcel of it to the changing needs of the people it must serve.

On Star Trek, the Borg were never defeated head-on with a brute show of force. But they could be overcome with finesse, using guile, creativity and perseverance. Those qualities will hopefully serve you well as you work on enrolling your reluctant enterprisers.

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

What Value Does a PM Provide at the End of a Project?

Written by Kevin Aguanno on . Posted in Articles. 8 Comments on What Value Does a PM Provide at the End of a Project?

The other day, I was challenged by a client to provide a description of why they still needed a PM at the end of their project. To understand their question, and my response, you need a bit of background information first.

This software development and package integration project had been running for several months, had completed the installation, custom development, and integration testing. Nearly all of the project team had been released from the project: only the lead programmer and a part time solution architect remained to deal with any issues arising during user acceptance testing (UAT), to answer questions from the client’s technical team who would be supporting the solution after the end of the project, and to provide some knowledge transfer to the client’s team on how to use the custom software solution. With such a small team (1.5 FTEs), low risk for failure, and only a few items left to complete with adequate hours remaining in the budget to complete them, the project was in a very enviable position.

The problem was that the schedule had been extended and, while there had been additional hours added for programmers to develop and test new functionality for the custom application, additional project management hours were not added with each change authorization signed between the two parties. Instead, with only a couple of project management hours left in the contract, I was negotiating with my client to have additional project management hours added in another change authorization.

The client refused the suggestion of additional project management hours, saying “We have our own project managers handling our portion of the project deliverables – they can also manage your two team members, in addition to their current teams, meaning that we don’t need any extra project management time from you.”

How do you respond to a statement like that? I suggested the following items to the client’s senior management chain:

  • Relying on Vendor Responsibility. The client had chosen my company as the vendor of services for this project because of our solid reputation in the marketplace and our long list of references. They were not just hiring a few of our staff members in a staff augmentation (a.k.a. “body shop”) mode; rather, they were buying our overall organizational expertise, tools, and processes to help them through the project. If they were to proceed without a project manager, and manage the resources directly, the client would in effect be absolving our company of further responsibility for the project, as our project manager ensures that issues of risk, governance, and our organizational commitment are being dealt with appropriately, including internal escalations, if necessary. With staff augmentation arrangements, such organizational commitment and responsibility rarely enter the relationship.
  • Financial Reporting Support. This client had asked several times during the project for financial reconciliations such as invoiced hours versus hours authorized in signed contracts and change authorization forms. As the project manager, it was my duty to provide this information to the client, whether I provided the information directly, or through an assistant. The programmer and solution architect remaining on the project would not have access to the correct systems to access the information required to respond to these requests.
  • Negotiating Changes. As we were in the final stages of the project (user acceptance testing and then deployment), issues and defects were arising that could have broader implications for the project as a whole. For example, one performance issue had a number of possible resolutions that needed to be evaluated, each with its own cost and benefits that needed to be discussed in detail with the client before a decision could be made. Neither the developer nor the architect had a technical focus, but the business impact of these resolutions spread more broadly than the technical impacts, and these technical resources didn’t have the business acumen to recognize or to communicate these impacts effectively with the business stakeholders. Finally, as the services vendor, we would need someone delegated with the authority (and with the right skills) to negotiate a solution that worked for both parties, including writing up the change, gathering estimates, calculating cost and schedule impacts, and getting the agreement signed by the right authorized parties. The technical people assigned to the team did not have these skills, which are typically found in project managers.
  • Focus on Customer Satisfaction: The personal performance of the resources left working on the project is measured with productivity metrics (like percent of worked hours billable to clients). This drives a certain behavior that is desirable in people building deliverables for a client: a single-minded focus on completing the solution. What is missing, is someone focused on customer satisfaction. In most organizations, customer satisfaction is used to evaluate project managers, who tend to have the most face-to-face interactions with senior business stakeholders (sponsors). The vendor’s sales staff (called “relationship managers”) are focused on customer satisfaction, as that is how they drive future sales; however, they are not typically focused on delivering contractual obligations and usually don’t have the authority and resources to make that happen. As the project manager tends to have stronger relationship-building skills, and the authority to shape the project processes to better influence customer satisfaction, it is in the client’s best interest to ensure that they still have some hours in the project for the vendor’s project manager.
  • Internal Escalations: Some issues and defects that were arising (and that would likely continue to arise as the project moves through UAT and into deployment) would require the coordination of vendor, customer, and subcontractor resources. This requires someone like a project manager who has experience navigating the vendor’s organization and who has familiarity with the vendor’s management processes and also the procurement (subcontractor) management processes.
  • Managing Vendor Resources: Even though the client thinks they can manage the vendor’s two project resources, what they are referring to are the work assignments and timing of delivery. There are other aspects to managing the vendor resources that they won’t want to do or cannot do: resolving personnel performance problems, approving vacation schedules, acquiring additional (or replacement) resources, resolving conflicts with the other projects being worked on by the part-time solution architect, etc. In many organizations, project managers take on broader human resource management roles than just task assignments.

So, even in the final weeks or days of a project, when most of the work has been completed and most of the team has been released to other projects, it is in the best interests of the project sponsor to retain the services of a project manager from the delivery organization.

Don’t forget to leave your comments below

The “Ideal” Iteration Length Revealed…

Written by Kevin Aguanno on . Posted in Articles. 6 Comments on The “Ideal” Iteration Length Revealed…

As agile project management methods are becoming more widely adopted in companies around the world, many of those companies struggle with one of the most basic decisions when starting iterative incremental project approaches: what is the ideal iteration length to use? Let’s see if we can tackle that question.

Definitions

First off, for those of you new to agile management concepts, an iteration is a defined timebox during which a portion of a solution is worked upon. There is a lot of misuse of this term, as many people mix up the terms iteration and increment.

Strictly defined, an iteration is a timebox used in an iterative project model. In an iterative model, a whole solution is developed over the course of a project, with snapshot views of “work in progress” being presented to the sponsor and/or stakeholders for feedback at the end of each timebox cycle, called an iteration. In this model, the solution is not completed and fully tested until the end of the project.

In an incremental project model, the aspects (features) of a solution are prioritized and are completed in order of priority. Each increment is a timebox during which a selected group of features are completed and fully tested. Under incremental approaches, there is no work in progress at the end of any increment. Instead, each timebox adds more complete, working features to the ones already developed, growing the completed solution over time.

Agile methods combine both iterative and incremental approaches. As such, a timebox in agile (also called an iteration) defines a cycle during which an increment of functionality is completed. Yet agile tends to have a broader view of the solution than pure incremental methods (more about that in a future article).

Standard Iteration Lengths

There is no consensus in the agile community on the ideal iteration length. The Scrum method suggests 3-4 weeks as an iteration length, while eXtreme Programming and Feature-Driven Development suggest 1-2 weeks.

When choosing a standard iteration length, you should consider your team’s maturity with agile methods. Generally speaking, teams new to agile should probably start with iterations on the longer side, and then choose shorter iterations as their expertise with the new methods improves.

That being said, the shorter the iteration length, the more a team needs to rely on automated tools to help with project work. In software development projects, this means automated build and automated testing tools, primarily. This is especially important in later iterations in the project, where there is a growing list of new features that need to be regression tested every iteration – eventually, they can’t be fully regression tested by hand in the available time.

Another factor to consider is the value that can be received through shorter versus longer iteration lengths. If you have limited opportunities to meet up with the sponsor and stakeholders to make end-of-iteration demonstrations and capture resulting feedback, then perhaps a longer length might be more realistic. On the other hand, if your sponsor is very concerned about eliminating risk in the project or if you want to build trust by showing rapid delivery of value in the early stages of a project, then perhaps shorter iterations are in order. You need to think about how you can optimize your delivery of business value through your iteration length. Business value is often measured in dollars, but it can also include other elements like strengthening relationships, risk reduction, improvements in service levels, rapid learning, and many more factors.

Variable Iteration Lengths

Having a defined iteration length for your project that does not vary helps the team “get into the groove” or adjust to the cadence/rhythm of working under, within a particular timebox. This iteration cadence is important in helping the team optimize their internal processes as the project proceeds through its multiple iterations. As well, it helps the team perform at higher levels, as the members can estimate more accurately and build more accurate plans.

There is a case, however, for occasionally varying iteration lengths within a project. While this can be a controversial position with some purists, it bears closer examination. In rare circumstances, it may make sense to break the cadence of the team to include a longer or shorter iteration for specific business reasons. Perhaps you have one large piece of work that cannot meaningfully be broken down into pieces small enough to fit into a single iteration. For example, if your project is to install and configure/customize some complex packaged software, perhaps the first iteration is to perform the base install, while future iterations are devoted to the customization of that package. In this case, the first iteration could be 3-4 weeks to get the base infrastructure set up and working, while future work could be a series of 2-week customization iterations. In another example, you may have standardized on 3-week iterations throughout a project to develop a new product, but then switch to a short series of 2-week iterations to rapidly adapt to feedback from key customers once the project has reached a critical mass of functionality, or after it has been announced at a key industry trade show. In both of these cases, there is a specific business benefit to varying the iteration length – though I am careful to point out that I am not suggesting that you vary the length of each iteration; what I am proposing is that there may be business value in switching iteration lengths during a project.

Please note, however, that switching iteration lengths does not come without cost. As mentioned before, you will likely break the cadence of the team, possibly reducing their performance slightly until they adjust to the new rhythm. Also, you’ll have to be careful with how you are tracking and forecasting using velocity, as the metrics will recalibrate as the iteration lengths change. You may not be able to reliably compare pre-change metrics with post-change metrics, at least not without detailed explanations and careful consideration.

Conclusion

Ultimately, there is no ideal answer to the iteration length question. What is important is that you choose a length that is suited to your team, the technology available, and the project context, and the business case. While you may start with a default iteration length for your organization, it is wise to consider all of the above factors and adjust that default length if it will help optimize your project, while still respecting overall organizational objectives.

Don’t forget to leave your comments below.

Cutting Project Costs with a Scalpel, Not a Chainsaw

Written by Curt Finch on . Posted in Articles. 13 Comments on Cutting Project Costs with a Scalpel, Not a Chainsaw

From 1945 to 1965, the financial market in the U.S. moved upward. It then moved sideways until 1982, and up again until 2000. Right now, we are engaged in another great sideways movement. It could continue for another decade or so, and as businesses fail and members of congress pound their fists, it is natural to fear for the future.

These types of fears can be especially dangerous for businesses, as management often makes unwise decisions out of panic. For example, they might cut employees or reduce spending on many projects and programs that are good for the company. Consequently, many companies that slash costs in response to an economic recession find themselves unable to achieve top-line growth when the recession ends.

Extreme cutting of people and projects can be avoided, or at the very least, they can be performed with more intelligent precision. All that are required to handle such problems the right way are per-customer per-project profitability metrics.

Understanding costs is the first step towards understanding profitability. Most managers know how profitable the company is in general, but few of them know how profitable it is on a per-product or per-customer basis. Yet this level of understanding is necessary in order to develop and implement the right growth strategy. Think of it as the difference between performing surgery with a scalpel and performing it with a chainsaw.

How to Cut Costs with Precision

So how can you possibly know where you should cut and where you should not? It is actually rather simple once you have the right data. As it stands today, do all of the executives in your company know which of your past projects were successful? How many employees worked on them? How much time and resources were spent on them? Do you know which of your clients are profitable and which ones you lose money on?

Having this kind of information available is crucial while planning future projects and budgets. It enables you to make much more informed, financially sound decisions.

If you don’t know your costs on a per-project basis, then you have no way to validate

future project estimates. Was your previous project estimate accurate, both in scope for time and budget, or was it completely unrealistic? Which processes are working for you and which need to be improved? There is no way to answer these questions unless you are tracking time on projects, and not knowing these answers is especially dangerous during a recession.

Where to Begin

Get your employees to track their time on a per-project basis. Yes, everyone hates timesheets, but they can make an enormous difference to the success of your business, especially when the economy is down. The time data you collect will alert you to when projects are in trouble much earlier, giving you the opportunity to do something about it before it is too late. You will also learn which projects are consuming too much time and which clients are cheapest to service. During an economic recession, you will be able to “fire” your unprofitable customers and work hard to keep the profitable ones happy.

Next Steps

Once your company is tracking time, you will need to add labor rates to the data. The time of one employee can cost the company more than the time of another, and those costs add up on major projects. It is also important to track all expenses. For instance, some projects and customers use up more travel expenses than others. Collecting all this data on a per-project basis can help you understand true direct per-project cost, giving management better insight into how to cut costs with precision.

It is also necessary to allocate indirect costs in order to paint the full picture of where your company spends money. There are two types of indirect costs: general indirect costs, such as rent, that need to be allocated across every project in the company, and semi-indirect costs, such as customer relationship management, which should be applied to all projects for the customer in question. For general indirect costs, you will need to create an allocation formula for each type: marketing, legal fees, office rent and electricity, etc. For semi-indirect costs, there is a different process. If you have a large customer you do multiple projects for, there are usually some costs that apply to those projects as a group, but not against any particular one of them. In this case, you might allocate these semi-indirect costs by revenue or direct cost over those projects.

Per- Project Profitability

Once you understand per-customer per-project profitability, you will have a significant advantage over your competitors, not only during a recession but during good times as well. They don’t know where their profits come from but you do, so when you have to make cuts, you can easily calculate ROI on various projects and isolate the unprofitable work. Regardless of the economic climate, knowing where you are profitable and where you are not is the only way to thrive in a competitive business environment.

Don’t forget to leave your comments below

Curt Finch is the CEO of Journyx. Journyx offers customers two solutions to reach the highest levels of profitability: Journyx Timesheet – a timesheet and expense management solution for the entire enterprise – and Journyx ProjectXecute – a solution that unites project and process planning with resource management. Journyx has thousands of customers worldwide and is the first and only company to establish Per Person/Per Project Profitability (P5), a proprietary process that enables customers to gather and analyze information to discover profit opportunities. Curt is an avid speaker and author, and recently published “All Your Money Won’t Another Minute Buy: Valuing Time as a Business Resource.” Curt authors a project management blog and you can follow him on Twitter.

Stealth Projects – Why Should We Care?

Written by Kiron Bondale on . Posted in Articles. 11 Comments on Stealth Projects – Why Should We Care?

Stealth ProjectsA stealth project is an initiative that was never formally sanctioned or approved. This is not a value judgment – many stealth projects are able to deliver worthwhile business outcomes, but at what cost?

Stealth projects have been portrayed as being one of the Four Horseman of the Project Portfolio Management Apocalypse. So why do they survive (and even thrive!) in many organizations?

A stealth project usually emerges when a customer knows that their request will not be addressed in a timely fashion and leverages their position, influence or relationships within the organization to get the work done.

Likely causes for this perception are:

  • The customer may feel that the request will not be perceived by the governance committee or decision makers as being as worthwhile or as urgent as other requests that are more likely to be approved
  • The customer may feel that the work intake process (the method by which requests are submitted, evaluated and either approved or rejected) is too onerous

Another possibility is that the customer may simply not know any better. They may have been used to going to their “favorite” resource in the past to get things done, and even if a work intake process has been implemented they may be unaware of it or be purposely ignoring it. We tend to repeat past behaviors that resulted in desired results where there were no negative consequences. If there were no repercussions in the past for not following proper work intake practices, this behavior will persist.

So why should we care about stealth projects?

  • They consume human and financial resources that should have been utilized on officially approved and prioritized initiatives. No organization today has the luxury of infinite resource capacity, so there is always an opportunity cost incurred by turning a blind eye to stealth projects.
  • They may not be executed following all required compliance policies and practices. When a project is initiated as a stealth project, it is a reasonable assumption that quality or regulatory assurance practices might have been missed. The result could be that the deliverables from the project incur a heavier operational support or regulatory compliance burden than those of properly sanctioned and managed projects.

How can we identify stealth projects? Organizations that have successfully implemented time capture systems have an advantage, but it could also be as simple as managers knowing what their teams are working on, and for the management team as a whole to be committed to identifying and exposing stealth projects.

The outcome should not solely be punishment of the originators of these projects. In many cases, the customer may be unaware of the proper work intake process or may be highlighting a scalability or flexibility issue with the process.

To weed out stealth projects, a well communicated, flexible and scalable work intake process coupled with management commitment to the process is essential. However, this needs to be balanced against fostering a culture that encourages the brainstorming and submission of creative, innovative ideas.

Don’t forget to leave your comments below