A common mistake I see, especially in large program execution is the PMO (or EPMO or whatever it is called nowadays) organization and its representatives try to focus teams around “structure” & “process.” And before you say “agile”, let me tell you that my experience in many cases has been that instead of the waterfall traditionalists, the Agile evangelists take over and insist on being pedantic about their structure (whatever that demands – a 30 day scrum instead of a 21 day scrum, user stories vs…………. the list is endless, unfortunately). Nothing inherently wrong about structure and process, but what they usually result in are “artifacts.” Now, at the core of any project – what your sponsors are looking for are outcomes! Not just that we met milestones and created deliverables, but that we made good on the original promise of the project. Here’s a classic example in a program aimed to build a new data warehouse for a Fortune 500 enterprise:
The project plan was structured around delivering iterative releases in multiple “waves.” Functionality would be phased in and users would be migrated from the existing warehouse in groups. All good. All aimed at pushing value quicker. Somewhere though – the planners lost sight of outcome vs milestones and deliverables. While the iterative nature of the plan looked good and each “release” seemed to be complete (“milestone”) in terms of production quality code, (“deliverable”) – in isolation – they didn’t provide holistic value (“outcome”) to the end users. The plan was structured around specific source systems – however every report/analysis/ad-hoc query that was functional required multiple sources. “Well,” the planners said “We know that! It’s just that we need to chunk the delivery into smaller portions and release quick and often. You know we are agile around here right?” “What about business value? How do we get adoption and value out of the first few “releases?” responded the poor business leads. Well, if you take the focus out of structure, process, methodology and concentrate on outcomes and value – the plan looks like this – still iterative, still in waves; however the first release is now a targeted release to satisfy the top 50 reports from the existing warehouse. This is usable, functional and showcases the new technology being used.
I know I am simplifying a lot of issues here, but the major message is to focus on outcomes to the exclusion of all else. Feel free to reach out to me via this blog and I will respond to questions and challenges!
Have an exceptional day!
Recently, I overheard a “professional” project manager talking to the technical lead about fast tracking. He was saying “well, since the architecture guys did not come through with their deliverables, we can use a technique called fast tracking and still try to meet project deadlines.” No doubt, this PMP certified project manager knew all about fast tracking (I’m sure there is a whole section on this –both in the exam as well as the multiple tomes from PMI!), but he was missing a key ingredient. There were some serious dependencies on outputs from missed tasks. Not necessarily ones that were clearly visible to him on the critical path in his “enterprise project management” tool, but ones that were embedded in the implicit nature of tasks – ones that needed counsel and advise from the SMEs on the team. Which he didn’’t think was necessary to listen to, since this was a “project management” task.
It is a fallacy to think that the scientific techniques taught in the so called “project management domain” can be literally applied to real life projects. Because real life projects contain two elements that mess up the works – (a) humans are involved in delivery and (b) you only know what you know and you don’t know what you don’t know.
A better way is to manage to outcomes rather than to deliverables. If all the stakeholders are in sync around the nature and characteristics of the outcome(s), then esoteric techniques can be eschewed and everyone can focus on the ultimate value to be delivered. Stay tuned for a series of posts on an emerging model based on “enterprise outcomes” rather than on “enterprise projects.”
Say you have acquired considerable experience in managing software development, with an impressive array of projects under your belt. You have executed a variety of projects and you have encountered most of the challenges thrown up in these types of activities. You know how to ensure that strategic objectives are met, valuable outcomes are derived and generally leave your customers (internal or external) satisfied with project delivery. Can you now assume the role of a PM for a construction project? Let’s say it is to build a bridge over a creek in your local county.
The question dear reader is this – can we treat domain experience as a “nice to have”, but insist that project management is a horizontal skill and discipline? Just to clarify – I am not talking about being a domain “SME” (Subject Matter Expert). Usually this discussion is confused by folks introducing the domain SME aspects of it. I think the real discussion should center around domain experience. Can an Agile PM well versed in cranking out software also be expected to manage bridge building? Why don’t you have a say – Click this link for a quick poll – you’ll see what our community thinks!
Here's a story about Kevin the enthusiastic (but maybe new?) PM, Grace the senior business analyst and Robert, the VP of Finance. It is a composite story and does reflect actual experience. But don't quote me on that!
Kevin rubbed his hands in anticipation. “Oh boy”, he thought. “This is awesome. I get to go completely greenfield on this.” Kevin was the project manager for a BI (business intelligence) project where a completely new reporting platform with a new data mart underneath were being implemented. During a planning exercise, the IT implementation team was discussing the notion that it would be great to gather requirements for all reports from scratch. They felt that they could avoid the mistakes of the past and really “get it right” this time. Kevin decided to go to the first of these gathering activities with the senior business analyst assigned to the task – Grace. During the planning exercise, Grace had been the lone voice of dissension – she had cautioned the team that to go to the VP of Finance and ask him “what are your report requirements?” would be dangerous. The team had disagreed and had come up with a detailed “deep dive” approach for report requirement gathering with discrete questions around needs, data elements, analytics, etc.
“Good morning. c’mon in” said Robert, the VP of Finance as Kevin and Grace stepped into his office. “Robert, it is great to see you and thank you for agreeing to meet with us” replied Kevin. “Oh definitely, this is very important to me personally as well as for the company – because we are finally going to solve the gap that we have today with discount reporting” said Robert. Kevin was pleased and began “Robert, we thought that since we are basically bringing in new technology and rebuilding the data mart and analytics from ground up, that we would basically walk you through a process where you can start defining your needs.” “Hmmmm”…..said Robert, “let’s see…..”
Kevin started to explain the process the team had thought through when he was interrupted by Robert, “Have you looked at our current reports – basically we are missing partner sales data – if I can get that and add the incentives and commissions, we will be golden. I don’t want to repeat all the existing report definitions – we have them exactly where we want them. You know Kevin, this is turning out to be a waste of my time and I wouldn’t let you meet with my teams if this is the process……” As Kevin started getting visions of the CIO’s reddening face when he reported status, Grace stepped in “Hey, Kevin you know maybe we can use these report screenshots we put together as prototypes and have Robert help us mark them up for the gap. “ Robert looked at the screenshots and immediately jumped on the idea. And he began to provide quality information…..
This, dear reader is when greenfield becomes a minefield. Listen, I love greenfield projects – I love to start with the ubiquitous “blank” sheet of paper too! However, there are very few circumstances where you can get away with forcing people to start from scratch. This is not to say that rethinking the way business is done, especially when multi-million dollar projects are being implemented, is a bad thing. However, it requires finesse and a platform based on current practices to really take off. Most business folk are tired of IT talking about “change management”, “we shouldn’t do the same old thing again”, “this is a great opportunity to blow up the old system” etc. etc. Because, in most cases, business usually feels that IT didn’t’ get it right the earlier times anyway – and they the business, through agonizing multiple “phases” have gotten their systems and practices to a certain operational level. Certainly they won’t want to start from scratch. The challenge for you is to show how you can leverage the existing platform and “transform while you perform.”
Keep having fun!
Listen, I know we have to get people to think about project management as a science; as a domain with "generally accepted" processes, steps and procdures. Legitimacy is important and I think as a collective, the entire project management community has done a lot to educate our organizations. As project managers if we focus exclusively on processes and artifacts, we will get to check off tasks and move them to completion. Let's take a look at what we achieve when we do this:
In my experience however - this focus on "task management" and "task completion" takes us farther and farther away from the real reason - our raison d'être as a profession....the actual outcome of the business initiative we are (or should be) engaged in!
How many times have you heard - "as the PM, you are ultimately responsible for this project." What they are saying of course, is that you are responsible to ensure the outcome of the initiative - not the completion of an elegant master project plan. To me, a focus on outcomes - changes our flavor from being "project managers" to "project leaders." And that is the evolution that is absolutely necessary to propel us and our domain to the next level of influence and impact in our organizations. A quick tip here to use as a daily leadership behavior:
Own the outcome, not the task. This is all about keeping your eye on why you are executing a task – i.e. how does your task combine with the tasks of others and move the dial. As you embrace this, you will move from responsibility, accountability to true ownership – where you don’t stop at a task completion level; (minimally acceptable - project management level) but operate at the outcome level (project leadership level).