PM Best Practice: Organizational Maturity

Showing posts with label Organizational Maturity. Show all posts

Thursday, August 14, 2014

Reconstructing Project Management (8 of 9)

Is Agile a project management discipline or really just a form of task or workstream management?

This is the penultimate entry in my series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal.

Agile is a mindset, not a methodology (or a process). PMBoK defines a Body of Knowledge for creating a methodology (and processes), but it is not a methodology. Agile is a way or practice or technique for delivering products or solutions. So are SEI’s Capability Maturity Model – Integrated (CMMI) and the Microsoft Solution Framework (MSF). Neither Agile, nor CMMI nor MSF are disciplines for delivering projects. (For more on the relevance of this, I refer you back to an early series on the P&SD PM, the Consultancy PM, and the philosophical relevance.)

Agilists are special only because they are so sensitive to anything that hints of management or structure. Working with agile teams is similar to working with many creative types: artists, painters, novelists, musicians and designers, for example.

What do we learn from this? That there is so much market demand for a product delivery solution with PMI’s imprimatur that PMI has responded by offering the PMI-ACP®. Should PMI also offer specialized domain-specific certifications for pharma research, product design, architecture, prototyping, etc? Likewise, should they offer project management certifications for CMMI and MSF shops?

So I wandered off the trail and fell off a cliff. Let’s get back on the main trail and respond to Morris’ question: What Agile is is really not relevant. That it’s not a discipline for delivering projects is all that matters. And PMI is losing focus by responding to these distractions.

I get to drill deeper into that last comment in my next post.

Saturday, July 5, 2014

Reconstructing Project Management (7 of 9)

Is program management just the management of projects with shared aims and possibly resources or does it have some special ownership of delivery of the business case benefits? If the latter, why? Shouldn’t projects also have this concern?

This is the seventh in my series of posts
commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. We are nearing completion of this series, with just a little wrap-up remaining.

In my previous post, I described a vision (or maybe it’s just a prediction) where senior leadership of the enterprise recognizes the value of enterprise (organizational) change management and the Project Management Office (PMO) is a strategically positioned general business service, on the order of Finance and HR.

In today’s world with generally weak PMOs, project management is in place to serve as agents of other organizational leaders – leaders who have strategic responsibility and delegate the tactical delivery to the PM agents. As PM continues to mature and organizations recognize the value of organizational change, PMO oversight and management of the organizational portfolio will elevate PMO leadership first to valuation of the profit-loss (revenue vs cost) of the change portfolio and eventually to recognition of the asset value of the project portfolio. This should happen naturally and organically, much as Finance moved from obscure back-office accounting responsibilities a century ago.

The real question is whether the leading project management organizations of today (such as PMI), recognize this evolution and take proactive measures to guide the future, or do they keep their feet securely grounded in the traditions of the profession and slowly wither into obscurity, or do they flounder reactively, without vision or philosophy, responding to the latest fad (to foreshadow the next post), until organizations realize that the value and esteem of the credential are so diminished that it is no longer relevant.

Here’s where I break with Morris: What’s the point of this question? What is a task? What is a project? What is a program? Yes, PMI has its definitions, but are they adequate? A project is composed of Deliverables, Activities and Tasks. A well-defined task has a single owner. It is a black box delegated to one person. But, let’s say an executive tells his assistant “I’m going to the convention. Get me a flight, hotel and car.” Is that a project or a task? It meets all of the components of the definition of a PMI project.

My point is that there is really nothing to distinguish a task from a project, except hierarchy. Further, if you conceptualize a well-defined program as consisting of projects and deliverables (within those projects), then there is nothing really to distinguish a project from a program except hierarchy. We have a natural recursive-descent system that just happens to have different names for nodes based on arbitrary values of size and scale (if you think that’s not true, compare your programs, projects, deliverables and tasks to NASA’s).

I realize Morris is trying to make a point about how PMI defines and explains these terms. But he’s fixated on arbitrary labels. To assume they’re inappropriate and then try to make sense of them just confuses me. If they’re wrong, just say they’re wrong and offer up the improved definitions, conceptual framework and explanations.

So project management, whether that’s managing programs, projects, tasks, activities, deliverables or recipes (just tossed that one in to see if you’re paying attention), as I’ve explained over the past several posts, has to have a tactical delivery component and, at some level and possibly formalized at some point in the future, the strategic organizational-benefit elements. It isn’t either-or. Though it may be temporally not now, but then.

Thursday, June 26, 2014

Reconstructing Project Management (6 of 9)

Should project managers work to achieve effectiveness goals (value, functionality, business performance) or just stay with efficiency ones (on time, in budget, to scope, etc.)?

This is the sixth in my series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. With this question, we transition to a new, much more comfortable, area of inquiry.

Is it possible to distinguish between what a project manager does and what project management is?

In these posts responding to Morris’ questions, I have generally taken a practical, realistic, down-to-earth perspective. In one way that makes sense: I’m a practicing PM who works in the enterprise; Morris is an academician. I am pointing out the practical, realistic flaws with what I see as his ideal vision. But that approach appears to put me in opposition to Morris.

And that is what is neither fair nor appropriate. I support his vision. It’s my vision, too. My comments are not for the purpose of shooting down and deriding Morris’ vision, but rather that in exposing the cracks, we can seal them and strengthen the foundation of a broader, more strategic profession of project management.

Mike Rother, in Toyota Kata (2010) describes the Toyota continuous improvement practice of establishing a target condition and then working to achieve it (chapter 5). The target condition has to be some better state and the approach for achieving it has to be unclear, to be determined. The target condition is some future ideal state that the worker then, in incremental, experimental steps, strives, with their supervisor, to achieve.

I hear in Morris’ questions: Are these the ideal states that the profession should be striving for (working toward) as the future of project management? If so, and I believe so, then what is the next incremental step to get us there?

I actually see us already progressing in the right direction, though fitfully and reactively, rather than strategically, proactively and guided by a philosophical/ academic vision. In the world of our past, companies were uncomfortable with change (projects), so they temporarily brought in specialists (PMs) to manage and drive the change. As companies become more comfortable with change, as they recognize that change is continuous and that it’s necessary for competitive advantage and survival, they are institutionalizing the organizational change capability into a permanent, operational component of the organization. It is called the Project Management Office (PMO).

With this evolution, the project manager role is changing. Historically, the PM’s value was as a hired gun brought in to deliver a higher-level vision – that is, deliver the tactical expertise for planning, managing and controlling time, cost and scope – for benefit of a change agent within the organization. This was how they were valued, rewarded, measured and compensated.

The PM of the future, though, will be a resource within the PMO. The PMO will be responsible for delivering the change and will have developed criteria and methodologies for doing so. The PM of the future will be rewarded, measured and compensated for compliance to and practice of the processes, use of the standard tools, and appropriate knowledge, skills and capabilities of the tools and processes.

So the flaw in Morris’ question, above, is that it should be “Should project management work to…” Project managers of the future will still do the same tactical activities they do now – maintain schedules, track costs, calculate earned value, identify and manage risks, etc. But they will do them following the proscribed processes of the PMO, rather than as craftsmen imbued with a mysterious skill. It is the PMO that will do the meta-activities of managing a project: Plan cost management, plan schedule management, plan risk management, plan procurement management, etc.

It is the PMO that will have the seat at the table to drive the enterprise effectiveness goals of the project, the program and the portfolio.

Regrettably, the poor PM of the future will not even have the golden triangle of constraints to point to when describing what they do. They will have to pull out a thick procedures manual instead.

The future is sunnier for the profession, but the professional suffers.

Tuesday, June 24, 2014

Reconstructing Project Management (5 of 9)

Does project management cover Estimating and Contracts and Procurement? Are they parts of the discipline? (Organizationally, they are often not treated this way.)

This is the fifth in my series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. Maybe I’ll finish this before the anniversary of its publication.

This is one of Morris’ questions that is a challenge to grasp because it seems the question is broken. After all, Estimating is clearly defined in PMBoK planning processes for both cost and time management. And Project Procurement Management is one of the 10 Knowledge Areas. Therefore project management (at least, the PMBoK) does cover both of these topics and they are inarguably part of the discipline. What is Morris thinking?

Let’s think for a moment about how a government agency awards a contract for road or bridge building. The agency will decide the road or bridge goes here, gets a budget allocated (estimation), buys up the necessary land (procurement) and only then issues the RFP for the engineering, design or construction firm to put steel and tarmac where the agency already decided it should go.

Lest you think that technology (my domain) is different, for large projects it is normal for executives to already have a cost limit, expected delivery date, expectation of technology partner, and whether the project will be done with in-house, outsourced or consulting resources – all before they let the project start through the official project methodology, phases and gates.

Morris expands further on this: “similarly the project management team should provide input into commercial matters, beginning with the project strategy and the choice of contracting strategy; in particular, what functions to contract out, what resources are available, and how risk should be allocated. These typically come under the purview of the ‘Contracts and Procurement’ function but since they can all massively influence the way the project is managed, one would expect the project director (or equivalent) to be engaged, shaping thinking and decisions. The alignment of supplier aims and practices with the sponsors’ aims should be a major objective in this new environment.” (p18)

Are those activities project management? Arguably, they are general (operational) business strategy and planning activities when they are done as part of business continuity, operations, development and growth. But they are project management activities when done within the milieu of the project. Should general business activities be project management when, ex post facto, they were done for what subsequently becomes a project?

I think it’s relevant to note a similarity that, in context, becomes, I guess, an analogy. In technology, teams are generally matrixed and split responsibilities between projects and operations. The operations responsibilities generally include support and maintenance. Maintenance is planned and can be coordinated with project activities. But support is on-demand and, on occasion, team members have to respond immediately to priority one situations that can take significant time away from the project. And regardless of the project state, the support activity always takes precedence. Ops trumps projects. It’s just the way it is. The point being, when the question arises, above, of whether these activities are operations or project, maybe ops trumps projects applies there, too.

Thursday, June 19, 2014

Reconstructing Project Management (4 of 9)

Should there be, resources allowing (personnel, funds), one [senior] person responsible for, and in charge of, the project from beginning-to-end? (What does ‘beginning-to-end’ really mean?)

Well, yes, of course. And with that I could be done with this post.

This is the fourth in my series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal.

The underlying intent of this question is, of course, much more complex and involved than a literal reading of the question indicates.

Morris, if I can presume to speak for him here, is implying that what we call project managers are only responsible for the tactical delivery of the project execution (monitor and control), but should be responsible for the strategic up-front initiation. What I don’t know is if he believes that the Executive Vice-President of Finance, who currently has those up-front responsibilities, should be labeled the project manager or just that the PM should be seated at the table when the EVP is thinking about initiating this project. I think realistic practice is that neither of those will (generally) happen any more than a department manager, who should be at the table when the executives are determining strategy for that department, will be there. (Though it may evolve that the Chief Project Officer (CPO) of the enterprise of the future is at the table.)

In a top-down, command-and-control organization, someone at the top decides something needs to be done, when they need it done by, how much they’re willing to spend to get it done, and, in many cases, various levels of detail about how it will be done. That executive who was there when the decision was made to start the project is responsible and considers the project benefit to them, so they don’t want someone else getting the credit for the project’s success. At the same time, that executive delegates, as they should, the tactical, day-to-day, delivery responsibilities of the project to someone who is qualified for that role and purpose. I’m sure it’s only coincidental that the executive now has a scapegoat if the project goes south (we had a great plan that showed it was a major benefit; it was only the delivery that failed).

So, executives should be held responsible just like bankers should’ve been responsible (i.e., paid the price) for the real estate collapse and financial meltdown, presidents should be held responsible for failed police actions and nation building across the globe, and officers shouldn’t get huge bonuses when their companies perform in the toilet.

I’m not being cynical (though I’m expressing cynicism with a broad, thick, dripping brush). In fact, that is the reality of political maneuvering and a demonstration of the skills that successful people have and are able to apply. If we called that top person a project manager and made them responsible, they’d still hire someone else for the delivery, delegate that responsibility to them and then take credit for the successful project while assigning responsibility for failure on the delivery technician, by whatever title. Label the boxes what you will, it doesn’t change the results.

The bottom line is that I’m responsible for monitoring and controlling a project (which implies relative to a plan). Delivering a result, a solution, a product or a service is not project management, whether it’s for an on-going operation or a temporary endeavor. Those things can be done without project management (e.g., CMMI).

Something is a project if and only if there’s a plan for delivering it and there is monitoring and controlling relative to that plan. The project manager is the person doing that monitoring and controlling, generally as a delegee on someone else’s behalf.

That’s what I do.

Saturday, June 14, 2014

Reconstructing Project Management (3 of 9)

When and how can we get away from a PMBOK that is based around what was chosen as being ‘the knowledge that is unique to project management’ rather than that which we need to know in order to develop and deliver projects successfully?

This is the third in my series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. This post takes up the third question, above, which needs a bit of context.

In the earliest editions of what is now PMBoK, PMI’s focus was only on the knowledge unique to project management, thus excluding general and domain-specific knowledge (though even this has questionable elements). So, to know what you needed to know to manage projects, you had to know the PMBoK content as well as other stuff.

Morris has a fixation on PMBoK, even though he identifies several other BOKs (APM, IPMA, ENAA and EPMF) that don’t have this omission or limitation he identifies. What I find most frustrating, though, when reading Morris is trying to determine what he means by the distinction of knowledge unique to PM vs what “we need to know in order to develop and deliver projects successfully.” This is a refrain from both the PMJ article and the book, but I struggle to find concrete examples of content that should be present but isn’t.

It’s frustrating because I want to agree with Morris that PMBoK is incomplete, but I don’t just want to know the disease, I want the prescription to treat it, too.

I think Morris is on much firmer grounding with his ninth question (to get ahead of myself) that challenges the foundation of PMBoK: is it a reactive response to what PMs do or is it grounded solidly and strategically on a valid logical/ philosophical model that defines and encompasses the PM domain. My interpretation is that PMI has been struggling over the past several years because their foundation is the Project Manager, but the future focus is on the PMO. That is, historically the PM was responsible for delivering the project and was therefore responsible for cost, schedule and scope.

In the future, the team and the sponsor will have responsibility. The PM will be responsible for (and measured by) following the processes and applying the tools that the PMO defines as appropriate within that organization for delivering successful projects.

PMI, thus, has lost its footing and is stumbling as it struggles to make this transition from the importance of the PM to the importance of PM processes. OPM3 has the potential to lead the way, but it goes back to Morris’ ninth question: is the PMBoK descriptive of what we do (and there are a lot of us doing a lot of different things called project management) or is it prescriptive and defining what is the domain and the boundaries of project management? The latter is strategic and provides the leadership and vision for the future. The former is historical and will be useful in a few years to analyze the demise of PMI.

Thursday, May 15, 2014

Reconstructing Project Management (2 of 9)

If it does not cover the front-end (a) is it fit-for-purpose (b) do we need an enlarged discipline or body of knowledge to cover what we need to know about managing the overall project? (Since managing the front-end is key (i) in building-in value (ii)in building-in [or out] future problems.)

Morris, Peter. Reconstructing Project Management Reprised: A Knowledge Perspective. Project Management Journal, Vol. 44, No. 5, October 2013, p13.

In my previous post, I noted that I have started a series of posts commenting on nine questions that Peter Morris asked in his October article in Project Management Journal. This post takes up the second question, above, which is a continuation of the previous post: what is the “scope” of project management?

Some executives are tossing around ideas for boosting revenue. They float this idea. They float that idea. At some point, somebody says, “That sounds good. Let’s do a quick reality check to see if we should commit budget for it.” If it doesn’t pan out – if it’s dropped without going through planning, execution and commission – was it ever a project? If not, then when does something become a project? When does this activity transition from on-going operational strategic leadership to a temporary endeavor?

If it does become a project, the vision, exploration and creation were surely part of the project, as was conceptualization, strategy, and the operational activities of enterprise leadership that normally precede “Let’s get a PM assigned.” But are these exploratory and creative activities part of what we would call the project before the fact? If they are, should a project management professional be engaged at these early stages?

How many project ideas have you known to originate from speculation about spending: “If we do this project, we’ll be so much better off because our expenses will be $xxx.” No, the project driver for discretionary projects is revenue and the factor that chills the enthusiasm is spending. So it is that Morris talks about the front-end activities – the pre-project activities – that are not considered project management and are the responsibility of executive leadership, whereas the PM is responsible for controlling spending.

Yet, how can you separate the Yang of expenses from the Yin of revenue? It wouldn’t be a project if it weren’t for the expected benefits. But Brent Flyvbjerg lists a host of reasons why technological (longest, tallest, fastest), political (monuments and attention), economic (making money off the project) and aesthetic (design and iconism) sublimes can lead project originators to exaggerate the benefits and underestimate costs and difficulties (“What you should know about Megaprojects and Why: An overview,” Project Management Journal, April/May 2014, vol 45 #2, 6-19).

Further, as Peter Taylor explained in the December 17, 2013 webinar (PMI and INPDCoP membership required) “The Journey of Expectation Management” for the PMI Innovation and New Product Development Community of Practice, expectations (and constraints) for projects are often set and locked in before the project manager is engaged. Yet, as Taylor goes on to say, it is the PM who is held responsible for project failure (often true even when the product is a resounding success: the PM for the Ford Taurus project was reprimanded for going over budget; the architect of the iconic, and 1,400% cost overrun, Sydney Opera House was so publicly humiliated that he never led another development of consequence).

Think about a bridge design where an artist and a financier draw up a bridge concept, go through the business case approval, then only bring in the engineer to monitor and control the construction. Would you want to cross that bridge? When we come down to it, isn’t that exactly what we have with projects? Engineering is a professional discipline and has licensing, legal precedent and authority for being engaged in civil projects. Is that what it would take to get PMs engaged at the start? Is that what it would take to eliminate Chaos from projects?

Monday, May 5, 2014

Reconstructing Project Management (1 of probably 9)

Does project management cover the management of the project front-end, the definitional, development stages, or is it concerned essentially only with execution delivery? What should it be responsible for? How far does it stretch into concept definition at one end and operations at the other?

Morris, Peter. Reconstructing Project Management Reprised: A Knowledge Perspective. Project Management Journal, Vol. 44, No. 5, October 2013, p13.

With this post I embark on what I hope will be a series of nine posts, which diverge considerably from how I have historically presented content on this blog. My focus has been on PM Best Practices and, as a practicing PM, my posts – at least from my perspective – have been intended as practical guides for the functioning PM in the trenches. For the next couple of months, however, I’m going to wander into the (cue theme from The Twilight Zone) wilderness of PM Existentialism.

Peter Morris authored Reconstructing Project Management (2013) and was invited by PMJ to encapsulate the book for its readers. If permitted (I’ve asked the publishers of PMJ for permission, which is still pending, to quote from the article for this series), I plan to take nine questions that Morris highlights in the article (Figure 3 Current issues in project management as a discipline, p13) and add my commentary and color, hopefully without getting too lost.

However, I don’t want to give the impression that Morris’ article is these nine questions (which, by the way, are also on page 111 in the book) or, even, that they are the central theme. In the article’s eighteen pages, Morris condenses, presumably, the topics, points, arguments and themes of two-thirds of his book. I’m pulling these nine questions, then, completely out of context and I encourage you to read the article (and the book) to understand his thesis. When I read these nine questions, though, they spoke to me so deeply that I felt compelled to explore them beyond the (here I avoid the use of “mere” or “just”, maybe “unadorned” works) concrete expression that Morris has given us. Further, I believe there is a tenuous link to my series on Governance.

By tossing these questions, like grenades, on the floor without further expanding on them, Morris challenges us to face the assumptions and core values that define our profession.

Practically a post’s worth of preamble, so let’s get to it…

Enterprise leadership holds their quarterly off-site to review strategy. They return and the business line VP needs to replace the legacy, proprietary application with a cloud-based SaaS application that is the market leader. She assigns a director responsibility for accomplishing this, who engages a manager to lead the day-to-day tactical project delivery effort. The manager, following the company’s methodology, prepares a business case, a charter, a staffing plan and a time and cost schedule. These are approved by the Director and the project kicks off.

Who is the project manager for this project?

There is so much depth and complexity in Morris’ first question (above). When I took the PMP certification exam, the model project manager we were told to visualize was the construction PM for whom a sponsor provided money in exchange for a commitment to scope and time. At that time I worked for a large IT consulting and project management company with aspirations of offering clients responsibility to deliver their projects – high value contracting based on responsibility for deliverables, not time and materials.

Fast forward to the world of today: that company is limping along as a has-been, ne’er-heard-of-‘em firm and the PM community is bifurcated between reality and wants. As a profession, we want responsibility for the projects, but in an enterprise reality where, instead, we are just responsible for delivery for someone else.

Executives, managers, and operations leadership make the strategic decisions about what projects to run and have ownership of the operational project decisions (funding, scope, who will be on the team and whether to pull the plug when things go akilter). They don’t want the mundane tactical responsibilities (and risks) of project delivery, but at the same time there are three market factors that prevent the elevation of professional project leaders into that sphere. First, those operational leaders, having gotten where they are, are not going to trust someone else with the responsibility (and esteem) for success with their vision. Second, without projects, their jobs are just, let’s face it, boring. Projects are the spice to the same daily gruel they otherwise consume (and that consumes them). They live vicariously through our efforts.

The third condition that reinforces the status quo is that, if other project managers are anything like me, we love delivering projects and don’t want those boring, mundane operational responsibilities. We are too happy doing what we’re doing to want to trade this for the better world where projects are run by project professionals, but at the cost that we are tied down to quarterly budget cycles, annual personnel reviews (which, btw, should be annual budget cycles and quarterly personnel reviews), product support and maintenance, and enforcing all the petty practices and policies of the very model of a modern major enterprise.

So we take the bones we’re fed, we deliver the project to scope, time and cost (or, in a more mature organization, to process), celebrate the successful delivery, hand it over to them to support, and happily walk away to pre-storm with our next project team.

Wednesday, April 23, 2014

The Tailoring Rule

"Professionalism is knowing how to do it, when to do it, and doing it.”

- Frank Tyger

When people choose to complain about project management, one frequent refrain is the burden and overhead of all that process. (I believe this is often a red herring, used by detractors who are concerned that project management best practices will expose their delivery weaknesses, but today’s discussion is to address the valid concerns for appropriate levels of process.)

A typical organization does many different types of projects of different sizes, styles and complexity. For example, an IT department might have projects for:

Infrastructure
New software development
Enhancement and maintenance
Product selection, acquisition and installation

Since all projects, regardless of size, style or complexity have many common elements necessary for success, does that mean that the organization only needs one methodology? Well, yes. And no.

If the organization has one bloated methodology dictating that all projects must produce all deliverables from identical templates, then those people who complain about too much process have a (partially) legitimate complaint. It’s legitimate because for most projects there will be too much process, but they are complaining about the wrong thing.

However, there are so many common and essential elements for project success that no organization wants to manage multiple (many? dozens?) of different, but similar processes. How to resolve this contradiction?

Both SEI’s CMMI and PMI’s PMBOK® Guide provide for Tailoring. Tailoring is an important but rarely formally practiced principle. In fact, in all of my years of consulting across a broad range of companies, I’ve encountered numerous cases where formal practices are ignored or circumvented because they are too onerous or just irrelevant, but in only one case have I worked at an organization that formalized process tailoring.

Even the description in PMBoK does little to suggest that the organization should establish tailoring in the formal processes: Initiation and Planning includes “guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project” (27). This description makes it sound like tailoring should be done inside the project to customize the organization’s standards rather than that the organization’s standards should specify the tailoring appropriate to different projects.

For example, an IT software development project, an IT software implementation project, an IT infrastructure project and a business process redesign project all have many similarities on how they should be run (they should all have charters, business cases, status meetings, risk logs, change management, etc.), but also significant differences (a new software development project won’t need the RFP activities in the implementation project and the BPR project will need a host of training and documentation activities that will not be needed for a back-office infrastructure project that has no end-user visibility).

Further, for a sufficiently small project, the charter could be fully contained within an email and the change approval process will need to be sufficiently streamlined, since long decision timeframes would jeopardize the delivery of the project. In contrast, a long, complex, risky project wouldn’t want to make change decisions too informally or too quickly.

The process burden needs to be appropriate to benefit the project – designating those best practices that best assure project success – while addressing project risk without over burdening the project. A requirements document for a small project might be a few pages, whereas the requirements document for a large, complex project could be a tome, with sections and subsections for business requirements, functional requirements, technical requirements, non-functional requirements, etc.

One size does fit all in project management, as long as that one size addresses the principles of successful project management. (Is that a tautology?) Organizations with best practices are clear about what processes are required and how those processes are customized based on type of project, complexity, size, risk.

The mistake often implied by those that complain about excessive process is that the situation would be better if there were no process. But processes evolved because lack of process (chaos) could not be relied on to consistently deliver successful projects, whereas the use of the processes improved the project success rate. The solution to excessive process burden (or bad process, for that matter) is not eliminating process. Rather, the solution is to fix the process through lessons learned and continuous process improvement.

Of course, organizations are even worse at lessons learned and process improvement than they are at projects. Look for my eventual series on lessons learned to address just this subject.

Friday, October 25, 2013

Project Governance – Maturity Level V

"There is a universality to comedy.”
- Simon Pegg

We have been building to this post for a while now. This is the final installment of my series on project governance – or, more accurately, governance in the project context. In the first post I introduced my arbitrary, tongue-in-cheek governance maturity level (gml). Having covered all of the descriptions for project governance maturity up to this point, it is now time to reveal the ultimate state of governance of interest to project managers.

Historically, the highest level of governance is some variation on the theme of continuous improvement or optimizing, but I announced in my previous post that that was not the case for this maturity model. And that post described the penultimate maturity level as alignment with organizational strategy, so what remains for the highest level of project governance maturity?

For strategic projects, there are really only three reasons that justify the project: it increases revenue; it reduces cost; it is a regulatory requirement. (Do you know of any other reasons that legitimately justify a strategic project?) For most enterprises, what department has the highest stature? Marketing? HR? Procurement? FINANCE (hint hint)? Of course it’s finance. And it’s time finance started seeing projects as generating revenue or reducing expenses.

In May, Angelo Baratta presented a webinar for PMI’s Information Systems Community of Practice titled “The Value Triple Constraint: Project Value Left Behind” (PMI and ISCoP membership required). In it, Baratta reminded us that projects have an economic benefit to the organization. So often as project managers, we are focused on cost (along with time and scope) and leave benefit and value to the cost-benefit analysis or the charter – and to bean counters or stakeholders with “higher pay grade.” But because there is this positive financial component, delays (among other choices) have a financial impact to the organization.

The highest level of project governance maturity, then, is when projects are recognized as enterprise assets. Just like raw materials and capital investments, we (the PM community) should be lobbying to have our projects recognized as corporate assets. This would immediately transition us to the big leagues. Our babies would be elevated in stature within the corporate and political pecking order. Project choices (delay, increase scope, cut scope, etc.) would have clear financial impact to the organization. Getting resources, as Baratta noted in his presentation, would be straightforward to justify when the alternatives can be quantified.

Of course, these benefits don’t come without perils, but such is the consequence of maturity. We will no longer be able to operate informally. We will operate in the spotlight. We will have to learn to speak “executive” (cut your vocabulary in half!). Risk management will impact the corporate risk profile. Governance in the project context will be integrated into the organization’s financial governance (think Sarbox).

One of the objectives of PMI is to have “Project Management” recognized as a discipline (or profession) distinct from “Management.” A step in this direction is to elevate the governance maturity and to transition project delivery from a technical discipline to a financial discipline with direct consequence for the enterprise bottom line.

From gml-I Chaos, gml-II Solution, gml-III Consultancy, and gml-IV Alignment, we have climbed the maturity staircase. Getting to gml-V Capitalized is governance your CFO would recognize – the next stage in PMI maturity.

Has this journey been worth it? What changes would you make to gml? Or how would you define a project governance maturity model?

Friday, September 27, 2013

Measuring Software Productivity

Enhancing the Efficiency and Effectiveness of Application Development. Michael Huskins, James Kaplan, and Krish Krishnakantham. August 2013. (registration required)

I just read this recent article from McKinsey and Company that extols the virtues of software productivity metrics, compares several alternative methods, and offers their recommendation.

I find it amazing that in the several years I have been publishing this blog, I have never discussed software productivity metrics – but after a review today, that is exactly what I found. As an avid advocate and proponent of metrics, the topic has certainly been on the list for discussion.

Had I written the article before today, I would’ve advocated Function Points. Function Points have several advantages, including being the most consistent, accurate and reliable of the various methods and the one most appropriate for evaluating and measuring vendor software. In particular, if you are comparing building a package versus buying a commercial (COTS) package for the same capability, then FPs offer an objective measure for comparing both features and cost to determine the appropriate path. Likewise, it is similarly appropriate when comparing products from multiple vendors.

As the McKinsey article explains, though, FPs are expensive and challenging to introduce. For organizations that rely primarily on software development (rather than purchasing vendor offerings), the McKinsey authors introduce a new (to me) method called Use Case Points, compare this to Lines of Code, Story Points, and FPs, and describe how to introduce UCPs into the organization. Further, the article notes that UCPs are comparable across applications and teams. And UCPs can be used with both agile and waterfall development methodologies.

I encourage you to take a look at this article for your application development environment. Metrics add a valuable tool to your toolbox. And metrics are an absolute, foundational necessity for continuous improvement.

Have you worked in an organization that uses software productivity metrics? What benefits did you find? What problems did you encounter?

Thursday, January 13, 2011

A Philosophy of Projects and Products (Part 3 of 3)

“We’re on schedule for development and plan to start testing next week,” an upbeat Dave updated his manager, John. John answered, “That’s good, but you’ve pulled developers from support to work OT to make the schedule, our support backlog is climbing, and now no one is available for the scheduled maintenance upgrade this weekend. We need to take a closer look at how you are deciding the team’s priorities.”

Over the past two blog entries, on P&SD PM and Consultancy PM, I discussed two distinct project management philosophies. This entry will discuss why this is important to a project manager, to a company hiring a project manager, to a company engaging a vendor of PM services, and to a supplier of PM services.

One area where the distinction is important is academia. In some circles there are efforts to create a distinct School of Project Management separate from the School of Management. Existing Management leadership resist this effort, answering that PM is just a variation of Management, not a distinct discipline. Looking at P&SD PM, one could argue that P&SD PM is, as they argue, just a variation; after all, it is generally found in organizations where PM is not a core competency, it serves the delivery of the organizations primary function, and general managers manage and utilize the PM services. Consultancy PM, on the other hand, is a distinct model of management; it doesn’t support an organization, it is the core competency of the organization.

Another area, closely related, is PM research. Little of the published research on project management, such as that in Project Management Journal, distinguishes among the types of project management being practiced and the results of the research. But what can be accurately inferred from the research when comparing such distinct practices as I’ve described in the two previous entries?

More relevant to the practicing project manager, especially one considering a career change, are the styles, cultures, practices, and expectations within organizations with the different PM environments. I’ve worked in both types and management expectations are crucially different. Further, the people – your managers and peers – in one are not likely to recognize the differences and prepare you for the changes.

As Peter M. Senge discusses in The Fifth Discipline: The Art & Practice of the Learning Organization (Doubleday, 1994), our mental models can artificially restrict our performance. Be prepared when moving from a P&SD PM culture to a Consultancy PM culture, or vice versa, to let go of restrictive workplace assumptions.

Finally, the PM Best Practice blog endeavors to advance organizational maturity and continuous improvement. The concepts explored in the P&SD PM environment and the Consultancy PM environment will be regularly revisited in future columns. PM best practices are different in these environments and trying to force a set of best practices appropriate for one onto the other is, at best, frustrating.

Do you see other significant ways that the P&SD PM and Consultancy PM environments are relevant to you as a project manager? If you’ve encountered any of the cultural differences that I describe, how did you adjust to them?

Thursday, December 23, 2010

Heroes

“Let’s give a big round of applause to Jeff for saving the eXrel project. It looked like a doomed effort until he stepped in and saved it for us - again. This is the third major project Jeff has salvaged in just two years.”

You do need to publicly recognize your team members who go the extra mile, but if your shop relies on heroes repeatedly, you need to step back and evaluate your operations. After all, this describes the chaotic environment that defines a maturity level 1 organization, where success is dependent on spectacular saves, monumental individual efforts, and the performance of key personnel.

Therefore, while you as a manager should recognize and reward your heroes, you should be asking why you are dependent on them and what you can do to sever that dependency. After all, there is a better way. Higher maturity shops operate in a more consistent, more reliable mode. In fact, in higher maturity organizations, there is rarely a need for heroes.

I can hear some readers saying that is because they plan better, and, while that is a true statement (if only because it is a tautology), it is more accurate to say that they can deliver to their plans. That is, they have a delivery capability that is reliably consistent and can be modeled successfully and the model will include the elements necessary for successful delivery. Their plans are realistic models of their actual delivery rather than the optimistic hopes and wishes of the planners dependent on good luck and herculean efforts of team members to bridge the gap between hope and reality.

So for executives as you observe, analyze and review your subordinate directors, divisions, managers, and departments, notice the ones that recognize their heroes. Those are the departments that probably need the most attention, coaching, and guidance to mature their operational processes. They are also the departments where you stand to gain the most from making improvements.

Thursday, December 16, 2010

Resource Management Maturity

Linda, the operations director, was again reviewing reports with her development manager Dennis. “I don’t understand why we continue to have this rolling bubble of demand in the next two weeks, then it drops off to nothing after a month?” The report Linda was reviewing was the resource demand report. “Every time we run this, no matter how much effort we’ve put into planning our resource needs, the report always shows we need 200% or 300% of our capacity for just the next couple of weeks, but then it rapidly drops off. But when we actually perform the work, we have adequate resources, but then the bubble shifts out in front of us again. What is going on, Dennis?”

Planning and scheduling for resource demand is always challenging. Just a few years ago, there were shops operating with excess headcount. Tales from those days might be mythic lore to today’s project teams. Some organizations are running well below necessary headcount. Getting projects completed while keeping up with support and maintenance demands requires constant rejuggling of priorities and resource assignments. People multitask. Team members are whipsawed from one must-do yesterday to another gotta-have-it-now today. They are heroes in their organizations, but this is nonetheless poor management and inefficient use of people (though, having been there, it still sometimes beats the alternative).

Interestingly, we can use these examples as heuristics to suggest the organization’s maturity level. For example, the organization that is scrambling, doesn’t know who is doing what, and is constantly changing assignments and priorities is clearly a Maturity Level 1 organization. A Maturity Level 2 shop is managing the portfolio of projects, initiates projects based on priority, has basic metrics (task estimates and resource usage), and generally has people assigned when and where they need to be (projects advance based on real-time availability), but limited predictive capability for planning what projects can be delivered based on resource capacity.

A Maturity Level 3 organization has reliable task effort estimates, team members report progress by updating their hours by task and re-estimate the remaining hours, resource schedules are based on productive effort, all resource hours are tracked (project, support, maintenance, admin, vacation, training, etc.), availability is projected based on historical trends, statistical allocations, and planned absences, so that theoretically management can predict which projects can be staffed. The reality, though, is the situation Linda and Dennis find themselves in. All the numbers are there, but there is still a fog of misinformation that separates ideality from reality.

Future posts will describe Maturity Level 4 and Maturity Level 5 organizations and address why Linda and Dennis are operating in a fog and what they can do to find the sunlight.

In the meantime, which example best describes your organization? Do you see value in raising your organizational maturity?