Skip to main content

Breaking Down the Functional Silos

Project managers can leverage several integration tools to make their work easier and complete projects with greater assurance that they will achieve the expected benefits.

What are these integration tools?

They come in several forms and extend beyond the project-centric processes outlined in the integration knowledge area of the PMBoK. Examples of organization-centric integration tools are SDLC and change management processes, and enterprise risk and project portfolio management programs.

These activities are management controls that cross functional boundaries. When management supports these controls they become very effective tools to ensure the right projects get the right resources at the right time.

Traditional functional groups are effectively silos and are limited by the budgeting process. Allocation of resources to projects often suffers due to political agendas or to ‘the squeaky wheel gets the grease’ syndrome.

Project managers struggle in these environments to properly resource their projects with the people they need. Strong project-based matrix organizations experience less tension between the functional structure, which tend to be vertical in nature, and the more horizontally focused projects. Nevertheless, these still experience some inefficiency in project execution due to conflicting priorities of functional and project managers.

So how do these organization-centric integration tools help?

Perhaps the more significant contribution is the increased transparency across the organization that these processes and programs bring. For example, a management review of the project portfolio dashboard is certain to prompt action, if a key project is noted consistently to be under resourced and behind schedule.

Similarly SDLC processes are well-understood, staged frameworks for cross-functional development teams to follow. Functional managers and the individuals in these teams become accountable for deliverables within these processes largely because they understand their role.

The same is true for the change management process which governs what, how and when changes to business processes will be conducted. In both cases clearly defined controls in the form of events such as change board meetings require multi-functional representation. Because of these integrating processes, the priorities of the functional groups transitions from department-specific, internal goals to supporting cross-functional project initiatives.

Recently, I’ve noted more than a few organizations that have taken an additional step to facilitate integration and increase the efficiency and effectiveness of their projects and programs. They’ve altered the organization structure to align developers to the more horizontally oriented project teams rather than to the hierarchical functional groups. The change is aimed at improving resource allocation and has the effect of transitioning an existing matrix organization to a more project-oriented and less functional operating framework.

This sort of change has been shown to reduce overhead costs and contention between functional and project managers. I like it because it goes another step towards making the project manager’s job easier by helping them leverage organization-centric tools even more.

 


Mike Lecky is a consultant at The Manta Group, a management consulting company specializing in IT governance, Project and Portfolio Management, Service Management, Risk and Compliance. Mike has degrees from the University of Waterloo (BScEng), The University of Western Ontario (MBA) and the University of Liverpool (MScIT). He worked for 12 years in aerospace electronics and as a Project Engineer managed several general aviation and US Military contracts. He teaches project management online with the School of Applied Technology at Humber College. Now, with over 25 years experience, he is a PMP and an information security professional (CISSP) and has a broad range of program and technology implementation experiences in the high tech and service sectors. Mike can be reached at [email protected]

 

Why Project Measurements are a Waste of Time

Everyone! Take 30 seconds and think about all the different measurements that one can use to evaluate a project’s success or failure. Here are a few to help you out: percentage complete; total budget savings; earned value; achievement of milestone dates; all requirements met; number of sites implemented; number of people trained; increased compliance, etc.

What do they all mean? Squat. Diddly. Zero. How can any of these measurements tell you whether or not the project is being run successfully? They cannot because you have nothing to compare against. It sounds like a great success story to say that 250 people were trained or that the program was rolled out to 50 sites, but what if there were actually 500 people that needed to be trained or the program needed to be rolled out to 100 sites. Makes a successful project look a lot worse doesn’t it?

This is the part where everyone is supposed to say that we need measurements in order to track progress and the success of the project. Why? Why do I need to track the hours it takes to perform every task? Should it matter that it was completed successfully or that it took 7.5 hours to complete? Why is that the measure of success? Ahhhh, right – BUDGETING. (I will save this topic for next month)

Now you say, well Andrew, if you are so smart and do not need these measurements, what do you use? I do use measurements, but in a typical PM scenario, you have no control over most of the decisions, so make sure the measurements do not reflect poorly on the project, when the project has no control over the decisions. Just because an organization decides to make a bad decision or a vendor decides to play hardball, why should the PM be penalized by missing deadlines? Then the project becomes “red” (oh no, not red!!!).

I prefer to look at what objectives the project is tracking against. What does success look like for the project sponsor? What will be the impact on the organization? These are questions that we as PMs should want to know, since we are responsible for the “successful” completion of the project.

Should the objective be to implement a new system at five sites in six months; or to provide access to technology for users at five sites that will reduce their administrative processing time by 25%, thus making them available for more value added activities?

You be the judge!

 


Andrew Miller is President of ACM Consulting Inc. (www.acmconsulting.ca), a company that provides supply chain and project management solutions. Andrew is PMP certified and has led a variety of clients through complex systems implementations and organizational changes. He is an Instructor of the Procurement and Contracting course, part of the Masters Certificate in Project Management program through the Schulich School of Business Executive Education Centre (SEEC) in Toronto. Andrew has an International MBA from the Schulich School of Business with majors in Logistics and Marketing. He can be reached at [email protected].

 

Making Sure that the Medium and the Message are in Synch

Editor’s Comments

“I want it yesterday,” is the clarion call of harried managers everywhere, pressed to deliver on time. Anyone who works from a home office or on the road knows the importance of the right tools and ground rules to let them work effectively. In her article, Virtual Velocity; Effective Project Management Gives Virtual Teams the Edge, Michelle LaBrosse gives us some pointers on how to put the communication tools and work culture together to reap the rewards of the virtual workforce, and bring projects to successful conclusions.

It’s also the cry of many project sponsors, who invariably throw in a couple of other requirements – that it be within scope and budget. But as Alan Koch reminds us in Negotiating the Triple Constraints, scope, cost and budget must be balanced to achieve project success. He also makes the point that many project sponsors either don’t know about the triple constraints, or don’t care….”I want it yesterday, come hell or high water!” It’s only later that the realities of scope, cost and time sink in.

On the blog front, Ilya Bogorad addresses what he describes as the most serious issue with project management today: The pointless project done well. Some of the most valuable resources a company can put together are wasted with the best of intentions. David Barrett discusses Project Management for the Masses, pointing out that there are many part time PMs out there who find the professional project management world intimidating, and he offers some help on how to adapt it to smaller projects. In his blog. Claude Emond talks about the importance of the project vision and regrets that many project managers he’s met dismiss it out of hand. Find out more in Vroom and the “Capability Principle.”

Thanks for joining us and let us know what you think.

Negotiating the Triple Constraints

We’ve heard it all before. The project sponsor announces, “Here’s what I need. I need it by the first of the month, and it can’t cost any more than this.” The project sponsor dictates scope, cost, and time and tells us that nothing is negotiable. That is what and when we must deliver, and, “Oh, by the way, the quality must be good, too!”

The Guide to the Project Management Body of Knowledge (PMBOK Guide) teaches us that every project is governed by the “Triple Constraints” of scope, cost, and time, and that they must be balanced with each other to achieve project success. But our project sponsor either doesn’t know about the Triple Constraints, or doesn’t care. The mandate is decreed and we are stuck with it!

Or are we?

Why the Unreasonable Demands?
Does our sponsor want the project to fail? Of course not! So, why are we given such unreasonable demands? If you look at the situation from the sponsor’s point of view, the demands start to make more sense.

Any manager in any organization (profit-making, non-profit, government, or whatever) is responsible for completing as much work as possible, as quickly as possible, and for the lowest cost possible. Managers who settle for anything less are shirking their fiduciary responsibility to the organization.

More often that not, the manager does not have a good way to estimate how much time and money a project should take. Even if this person has past experience with this sort of project, it is unlikely that he/she has the time to analyze it and consider all of its ramifications. When it comes to setting the constraints for the project, a manager who is serious about fiduciary responsibilities will push you hard, and then will push you just a little bit more.

The unreasonable demands stem from the project sponsor not knowing what the project will require, so he/she makes a best guess, then pushes beyond it to ensure that the project time and money are well spent.

What Can We Do About This?
Embarking on a project when we know it cannot be completed with the available resources is called a “Death March.” If we simply march forward, we know that the project will fail, and we will suffer as a consequence.

But if we object, we are often told to stop whining and get back to work. We can tell the sponsor that we don’t think the project can be completed with the given resources, but we are likely to be told that we can and we will! It is our opinion versus that of the sponsor – and with the difference in position, our hands are tied.

While it is true that we do not have the authority to argue with management, we do have some tools that can help level the playing field: hard data and useful information. Our sponsor doesn’t want to do the wrong thing, but probably lacks the information necessary to make the right decision. And we have that information!

We can level the field and prepare to have a meaningful negotiation with our project sponsor by following a simple three-step process:

  1. List the project activities. Follow disciplined planning procedures to identify all of the steps that will impact project success. Be careful to think through all of the work that must happen using past projects as a guide to be sure you don’t miss anything. 
  2. Research past projects. Understand the time and resources that those activities have normally required for success on past projects. (Or at least determine which resource levels were insufficient on past projects and use them to estimate what would have been needed.)
  3. Produce three solid defensible plans. With the information from steps one and two, you can now produce three plans. Why three plans? The first plan will reflect exactly what the project (as defined by the sponsor) will actually cost in both time and money. The other two plans suggest alternatives that could come closer to meeting the constraints: perhaps one that has a smaller scope and meets the cost and schedule constraints, and another that meets the schedule and scope by increasing costs.

Armed with all of this information, we are prepared to actually negotiate with management!

The Negotiation
Most managers have had little experience with receiving well prepared and defensible plans, so you are likely to be met with a barrage of questions about your plans and the data on which they are based. Don’t be discouraged by such a reception. It is management’s responsibility not just to trust what they are told, but also to ensure that it is realistic and is based on real data. It may take some time to convince your sponsor that your plans and your data are based in reality, and, depending on how positive or negative your relationship has been in the past, it may take a project or two before your sponsor begins to believe you.

When your sponsor begins to believe in your data, you are finally in the position to negotiate project constraints that are workable and realistic. What the project ends up looking like is up to your sponsor. While your sponsor may make choices with which you disagree, as long as you provide the information necessary to make good, rational decisions, you have done your part to ensure successful project planning.


About the author
Alan S. Koch, PMP, is a writer on effective Project Management methods and instructor for Global Knowledge. His 29 years in software development include over five years in Quality Assurance (including establishing & managing a QA department), and eight years in Software Process Improvement. This article was originally published in Global Knowledge’s Management in Motion e-newsletter. Global Knowledge (www.globalknowledge.com/PMILocal)
 delivers comprehensive hands-on project management, business process, and professional skills training. Visit our Knowledge Center at for free white papers, webinars, and more.

Copyright © Global Knowledge Training LLC. All rights reserved.

Vroom and the Capability Principle

From Sharing the Project Vision to Successfully Delivering Projects

I still meet many project managers who just state that sharing a project vision (if ever there is one) is a waste of time and that the project team should just concentrate on what they are asked (told ?) to do. This always reminds me of my first project management courses, more than 30 years ago (dinosaurs were still alive), when I was told that: “the more information people have about a project, the more veto power we are giving them…so it is important to keep information sharing to the strict minimum, using as a strict yardstick of information distribution “direct-task-oriented need-to-know information.”

I am appalled to see that this primitive belief still endures today, since it shows so little understanding of how human minds and hearts really work. I am also appalled that, each time I ask about Vroom’s Expectancy Theory of Motivation i (dating back from the early 1960s) and it’s significance to project management audiences (including many PMPs), I find out that it is still mostly unheard of or, when it is known, it rings no bell about the relationship between sharing a project vision and mobilizing project teams to ensure project success. This is very unfortunate since Vroom’s simple theory:

  • Holds the explanation to most “resistance to change” situations (the 9th waste of bad project management, identified by Bodek ii)
  • Shows, subsequently, the inescapable way to individual motivation and subsequent team mobilisation
  • Tells you, consequently, how you can deliver your projects faster
  • Gives you the ultimate behaviour-influence recipe for fast, mostly resistance-free, successful project delivery

What Vroom reveals to us is what I call the “Capability Principle,” which I describe as follows:
“A person will do something only if that person is convinced that he/she is capable of accomplishing what is asked from her/him.”

So when one is asked to do a task or to accept a new situation (a “change” in project management jargon), one must first answer a firm YES to the question “Can I do this/can I function in this new situation?” before even considering the usual existential pros and cons of the WIIFM iii type. Unless one understands fully where one’s project tasks and own ultimate fate fit in a project plan and in the subsequent vision this project serves, one cannot answer a firm YES to this question. The answer will be: “I do not know enough about this stuff, I am in no position of knowing if I am really CAPABLE of doing this or stand this….so I’ll wait and see and won’t accept personal responsibility or accountability for any of this”. So the project manager, who does not clarify nor share the whole picture of a project and its underlying vision, will end up either doing this other person’s work or telling this person exactly HOW to do everything; and, in so doing, this project manager won’t we able to share accountability with the project team.

You think that sharing a project vision is a waste of time? Well, the “Capability Principle” will prove you wrong. You will experience, first-hand, massive resistance to change and unshared accountability on your projects. And you will end up being the only one, all alone, caring for this project, the perfect scapegoat for a disaster in the making?

i http://www.valuebasedmanagement.net/methods_vroom_expectancy_theory.html
ii http://www.reformingprojectmanagement.com/2007/10/09/841/
iii What’s in it for me ?