This one seems like such a no-brainer that we don't even need to discuss it. So, why post it then?
Because I still encouter people on a regular basis that discuss Software Engineering in the context of Project Management who fail to make the distinction between the Software Development LifeCycle (SDLC) and the Project Execution Process (PEP).
This failure to recognize the larger process has a litany of perils associated with it and it deserves some discussion as a way to put the PEP back in the Project Driver's Seat.
No Matter which SDLC your company or team has embraced it is probably safe to say that it is a set of processes and procedures that govern the way in which we develop software products and ultimately deliver them to their customer or sponsor.
Whether it be Agile Methodologies, Waterfall, or Spiral methodologies, the mechanics may be very different but the goals, objectives, and overall outline remain similar. Plan, Design, Develop, Test, etc.
PEP
There are many different variations on this theme but most Project Execution Process maps have a “beginning”, where the products or services are brainstormed, a “middle”, where the products or services are developed, and an “end”, where the product is ultimately delivered.
Initiate, Plan, Execute, Deliver
Again, a no-brainer.
Confusion
The problem occurs when someone involved in the SDLC views the project as "Complete" when the software product is delivered. An even bigger problem occurs when the Project Manager makes this mistake because the entire project or program is jeopardized when those responsible for "The Project" take the view that "The PRODUCT" is "The Project".
What's the Difference?
In short, the difference between the two is the level at which you focus on deliverables. For example, while the SDLC requires that we Plan, Design, and Develop, most of those activities actually take place within the "Execution" phase of the PEP. So, why does SDLC "Planning" take place in the "Execution" portion of the PEP and not in the "Planning" portion?
This answer lies in the true understanding of Project Execution instead of in the imagined nature of Project Management.
For example, there may be a great deal of prework that goes into getting approval to begin a project and get budgetary approval. So "Initiating" in the PEP speaks to gathering the necessary approach documents, approvals, impact studies, and the like. One could argue that you could start Planning the software engineering portion of the project at this time, but if you do that you run the risks that the budget could be refused or that the project simply doesn't survive the first Go/No-Go decision.
In the context of the PEP, the Software Engineering Team would not be engaged until after the necessary funding has been secured and the project is already on the strategic roadmap.
Further, in the “Closing” portion of the PEP, there may be a rather involved process by which the product is delivered and aftercare undertaken to which the SDLC is oblivious. Contracts that require closure, marketing endeavors that must cease, post-mortem PEP activities, etc.
Closing
So, while some people tend to think in terms of the PEP and the SDLC as one in the same, it is more accurate (and safer!) from the Project Manager and Leadership perspective, to consider the SDLC as simply a set of critical activities that takes place during PEP “Execution”.
I am certainly not telling you that someone doesn’t need to manage the SDLC as a project, I am simply telling you that it should be part of our jobs to make sure we can see above the here-and-now and think in much broader terms for greater Project Success.
]]>We’ll begin by saying that this entry is specifically aimed at “Maintenance” or “Operational” activities and can be considered Part 1 of a multi-part series on bringing sanity to these necessary and challenging activities.
Before the purists begin to revolt at my last statement, let me say that there is a dangerous fallacy in trying to manage Operational activities as "Projects" and that is precisely what I intend to discuss here.
I hope that quelled the uprising.
]]> All humor aside, it is important to acknowledge that we are already on thin ice when we try to treat Operational activities as projects because, by shear definition, a project creates a unique product or service and has a definite beginning and end. This definition is in diametric opposition to the nature of Operational work.While it is not advisable to treat Operational work as “projects” and while I can appreciate the differences between the two types of activities, it is part and parcel of my job to try to find ways to apply the right amount of discipline to the right activities. This sometimes includes trying to apply some Project Management principles to “Real World” activities that may not fit nicely into the “Project Task” or “Operational Task” buckets.
The Bigger Question(s)
So, exactly how do we handle the type of work that arises on a day-to-day basis and competes for the attention of otherwise assigned Project Resources?
This is an extremely complex question and cannot be answered without understanding the totality of circumstances but we can begin by acknowledging that sometimes Project Resources are assigned to two pools of work; maintenance and systems health in addition to project activities. Again, a thin ice circumstance but a real world business problem nonetheless.
In the coming installments, we will focus on specific solutions but be assured that small projects and certain types of “unclassified” (under radar) activities can benefit from PM Disciplines more than one might think. In fact, it may be the answer to your current project quandary.
Stay Tuned, More to come!
]]>Project Recovery is the effort and activities related to addressing troubled projects. In other words, the activities that lead you to recognize that the project is troubled, then bring you to a decision point on whether or not to save that project, then those activities you might undertake to drive that project to completion.
]]> Let's take this a little further.To Recover or Not to Recover, that is the question
Most people I talk to who are involved in some kind of project recovery effort are already making the assumption that they are going to rescue it. Not necessarily so. The events and conditions that lead you to initiate a project may have changed significantly over the life of the project and it is important to review those conditions (business drivers, project ROI, strategic company initiative) before deciding to rescue a project.
For example, let's say that you are involved in a project that was undertaken initially as a way to increase profit margins on an existing product. However, the project has a delivery date that is dictated by some kind of market driver such as a conference, trade show, or even an event such as the Christmas holiday season.
When it becomes apparent that the product cannot be delivered by the driver date then one must consider the original objectives for the project and determine whether or not the expected RIO can still be met even though the driver date cannot be met.
The same can be said of features and functions. Even though you could deliver the product by the driver date, you would have to scale back what features or functions you could deliver, in which case the original objectives should be reviewed. It may not make sense to continue if the key features of the product were some of the main objectives behind the project undertaking and they could not be delivered.
How to Recover
The answer to this question is different for each and every project and has a great deal to do with corporate culture, the business you are in, your market influences, executive support for the project (or lack thereof), and a litany of other factors.
Although, at it's core, Project Recovery is very simply about managing the quadruple constraints of Time, Cost, Scope, and the forth constraint, Quality. Project recovery can be the juggling act of determining which of these factors is most important and using tools and techniques that support the driving influences.
For example, if you are behind schedule, there may be some schedule compression techniques that can be used but they will pull on another of the constraints, Cost. Here's nnother example: say you have plenty of money to fund the project and you may be able to add resources or partner with a vendor, however, the type of work that is outstanding is not conducive to large teams or vendor support.
Conclusion
Whether you decide to undertake the effort on your own or partner with a vendor to address a troubled project, there are a litany of factors that play into Project Recovery efforts and all should be reviewed and considered carefully before running headlong into a rescue situation.
]]>This post is dedicated to a better understanding of what a Project Manager is and what a Project Manager does. Just as important, we will also be talking about what a Project Managser isn't.
I feel compelled because I have heard the following conversation take place in every company for which I have provided services, ever.
]]> The ScenarioLeadership Figure: "I feel like this project is important enough to have a full-time Project Manager and I think you [insert name here], would be the best choice. You have the technical knowledge and you know the scheduling tool so it should be a no-brainer for you. What do you think?"
Technical Talent: "I think it is a great idea, but if I'm managing The Project full-time, who will be responsible for my technical pieces of The Project?"
Leadership Figure: Well, I think there is enough time for you to do both. Just put in a few extra hours each week to update the schedule and we'll still be able to make the deadline. . . . . . "
Technical Talent: "Um, OK, I'll do my best . . . . "
Chances are, everyone reading this has heard or seen something similar, and with just a few short sentences you can see where this is going. In the case that you haven't been a victim of this kind of drive-by PM'ing, or know someone who has, I'll draw out the rest of the above project scenario in shorthand.
Before I can draw out the rest of the scenario, let's make a few assertions to set the stage.
Assertions
1) The Leadership Figure is truly interested in seeing the project succeed and he/she is thinking about the right things when asking to place a PM on an important project.
2) The Technical Talent knows something of Project Management (how to work the scheduling tool) but isn't necessarily what one would deem a "Project Manager".
3) The Technical Talent has many other leadership responsibilities such as "Technical Lead", "Application Architect", etc.
4) The Technical Talent is truly committed to making the project work and is willing to do whatever is necessary, including take on extra responsibility, to make the project work.
Playing It Out
OK. I'm going to make some generalizations here so let's assume for our purposes that the statements I am about to make apply most, but not all of the time.
1) The Leadership Figure becomes disenchated with PM results or Project Deliverables or both because there was an assumption that both could be done on a part-time basis.
2) The Technical Talent becomes disenchanted because they have been placed in a situation where there is no potential for success.
3) The company/ultimate customer loses because the Project will slip off schedule. Deliverables rejected, milestones missed, cost overruns, scope creep, name it.
This is partly due to Leadership Figures's naivete, partially due to the lack of PM skills in the Technical Talent, and partly due to timeslicing on an already overallocated resource (Technical Talent).
What Went Right
The thing that went most correctly in the above scenario was the Leadership Figure's recognition that he/she needed to apply some PM wisdom to the project. Although this was a misguided attempt, simple recognition is a good start.
What Went Wrong
While the Leadship in this case has good intentions, he/she is not seasoned enough themselves to understand what "Project Management" really is.
The key Technical person should have recognized that their Technical responsibilities on a key initiative were far too demanding to allow him/her to timeslice.
Summary
Asking a key Technical person to take on Project Management responsibilities is NOT a good idea unless that person is properly trained in PM Disciplines and you are going to adjust your technical expectations from that person.
In other words, assigning a PM is not magic, it is just like filling any other position in your organization. Start by working with your HR people to open a job title and description that accurately reflects your needs and then prepare a budget for having projects properly managed in your organization now and in the future.
Do your people, your company, and your project, a service and make sure you spend the proper amount of time in selecting the proper talent to manage your project.
]]>Although, in considering the notion in greater detail, we have tasked our Project Managers with ultimate delivery of important products and services and we would be foolish to trust ultimate delivery of key products and services to a gatekeeper that is simply responsible for managing the project schedule.
]]> Ability to DeliverIf you are going to trust ultimate delivery of key products and services or strategic initiatives to an individual, you would probably expect that person to possess a breadth and depth of knowledge that gives you confidence in their ability to deliver. In searching for someone to drive delivery you might look for the following set of skills, experience, and qualities, in addition to a proven track record:These are just some of the skills you might look for and it is already a pretty long list of highly valuable skills and experience. In fact, this is the same set of skills and experience you might be searching for if you were looking for a Senior-level Executive or a key decision-maker. By looking at this list, it almost sounds as if you are searching for a Leader. It is true, the PM set of skills and experience are very similar to the assets you might look for in a good Leader. To further the thought, you might even begin to think about the Leaders in your profession and then begin to ask if they possess the necessary skills and experience to get the jobs done.
Practical Abilities
More and more often, corporations are asking this very question. Do our leaders have the necessary skills to meet the goals and expectations set forth by the company? An MBA or PHD or other academic achievements do not necessarily guarantee success or attest to the practical ability of individuals to achieve corporate goals.
So, how do we increase our level of confidence in the ability of our people to execute and reach goals? Increasingly, the answer to this question is "Project Management Skills Training".It seems counter-intuitive at first but when placed in the context of analyzing risk, managing issues, managing large and highly dispersed teams, and the like, it makes a great deal of sense. In addition, if we equip our leadership staff with disciplined execution skills then the phenomenon of top-down culture change begins and becomes infectious within an organization.
When asked who should attend a PM training course, I recommend having a good mix of technical people, project managers, product managers, support staff, business analysts and leadership staff so that Project Management principles begin to get a foothold in every area of the product lifecycle.In Closing
From those people that gather requirements, to those that support the products in production, to those that are setting the strategic direction of a company, Project Management principles are truly skills for Leadership, not just for Project Management staff.
]]>Let's start with "the definitions":
Cost Performance IndexSimply put, this is the number that tells us that for every dollar we spend on a project, how much value are we getting back out of the project in progress or deliverables. The number derived in CPI should be a number that it somewhere in the neighborhood of 1.0 +/-. Plus or minus because a 1.0 would normally be interpreted as getting exactly one dollar of progress or deliverable for every dollar spent to achieve the objectives. 1.25 would be interpreted as getting $1.25 of value for every $1 spent and .75 would mean that you're only getting $.75 progress for every $1.00 you're spending.
What Does it Mean?
So, if you're tracking .75 CPI you should be looking for ways to get more progress out of each dollar budgeted and you should be staying up at night knowing that your project is bleeding cash. Maybe even working on your resume.Conversely, it would follow that if you're tracking 1.25 CPI that you should feel good that you're getting $1.25 in progress for every $1.00 you spend. WHAT A DEAL! You're probably in line for a bonus.
The Fallacy
I hate to fling the wet-blanket on your project party, but there is a fallacy to be discovered here.I, for one, get VERY uneasy when I see a project performing far above calculations when it comes to CPI. Further, I don't dispair too deeply when I see the CPI calculations performing below target either.
Why? Aren't Project Managers supposed to get excited about this stuff? If not us, then who?Here's the fallacy: The chances are good that if your CPI indicates that you are consistently getting more than $1 value for every $1 you spend then it probably means that your baseline estimates and budgets are flawed. Think about it, if you consistently come in under budget, then wouldn't it make more sense that you're overestimating rather than achieving the amazing on a daily basis?
On the other side of that equation, just because you're CPI consistently indicates that you're only getting $.75 progress for every $1 spent, it doesn't necessarily mean that your project team is a consistent failure. It may simply indicate that your estimates and baseline budget were/are flawed to the downside or underestimated.
Again, there could be many reasons that your CPI could cause you to make erroneous conclusions about your project. The bottom line is that you need to look beyond the numbers and begin to determine the why.In Closing
SPI is calculated and interpreted in a similar fashion and has the same potential for misinterpretation, so I won't get into an identical diatribe abuout SPI.When looking at either CPI or SPI, a good PM will always try to determine the underlying causal relationships that bring us these calculations and make good project decisions based on the real factors at work. This will lead us to better project decisions and give us a greater horizon for guiding a project through rough water.
Dont get me wrong, CPI and SPI are extremely valuable. Just make sure that the story they're telling you is true and that you aren't buying into a false sense of accomplishment or dispair.
Jason Becker, PMP, CPM
]]>As a Project Recovery Specialist, I am constantly reminded of the perils of attempting to save the wrong project for the wrong reasons. While the reasons one might choose to attempt to save a project are relatively simple, the reasons one might choose not to save a project can be much more complex.
]]> When considering whether or not to rescue a floundering project one must ponder several factors: 1) The level of importance the ownership organization places on the project
2) The alignment of the project to strategic goals or business objectives
3) The level of commitment the ownership organization demonstrates to project success
4) The motivation of the ownership organization for considering project rescue
Let's delve into these one by one:
The level of importance the ownership organization places on the project.
This question is critical because there would be little reason to go through a Project Recovery process for a project that is of little importance to an organization. Although it seems like a simple question, it can be difficult to answer because the Project Sponsor will always convey to you that the project in question is of critical importance to his/her organization. The previous statement is not meant to infer that your Project Sponsor is intentionally misleading you. It simply means that the Project Sponsor has an emotional or professional attachment to a project and will have difficulty seeing the "big picture". This is where a good Project Manager brings experience to bear in stepping a level above the details and beginning to relate this project to the other project in the portfolio and begin to determine the true level of importance to the overall organization.
The alignment of the project to strategic goals or business objectives
Determining the answer to this question will help you begin to discover whether or not you are going to get the support necessary to successfully recover a troubled project. When a project is poorly aligned with strategic or business goals, it is almost a certainty that you will have difficulty in gathering the necessary support to successfully rescue the project.
Another factor here is one of financial viability. A project may have begun with certain Return On Investment requirements and undertaking a Project Recovery effort may undermine the fundamental reasons the project was undertaken in the first place. Knowing the original success criteria is of critical importance when considering Project Recovery.
The level of commitment the ownership organization demonstrates to project success
Simply knowing that the project is well-aligned with strategic goals and, therefore, is of importance to an organization is not enough to make a decision on whether or not to proceed with Project Recovery. You need to ensure that there is a true commitment on the part of the ownership organization to rescue the project. Project Recovery is typically expensive, time-consuming, and somewhat painful. Knowing this, there is little reason to undertake an expensive, lengthy, and difficult process unless an organization is committed to project success at the very highest levels.
The motivation of the ownership organization for considering project rescue
Finally, understanding why an organization wants to rescue a project is of critical importance as well. Someone with an emotional attachment to a project may have a need to rescue the project as a way of "saving face" or meeting a financial bonus goal. These aren't necessarily bad reasons to want to rescue a project. However, because Project Recovery typically requires a great deal of support across multiple business verticals, you may find that while the Sponsor will give you unlimited support, the other key players have little interest in saving the project because there isn't anything in it for them personally.
In Closing
Simply because you can rescue a troubled project or because you have the budget to attempt Project Recovery doesn't necessarily mean that it is a good idea. It is important to treat Project Recovery as if it is new project with a personality all of it's own vs. thinking of it as an extension of the original project. If you think of it in this way, you are much more likely to make sound and reliable decisions about how and when you should attempt a recovery effort.Jason Becker, PMP, CPM
jason.becker@axisitconsulting.com
Most PM's and Executives struggle with this question because it seems as if a rigid and thick process can kill smaller projects and at the same time a very lightweight and agile process may not be enough to guide a complex project to success.
]]> So, how much process is enough for any given project? It seems impossible to answer this question without knowing the depth and scope of a project but there is a short and sweet answer to this question that, if considered when pondering any Project Management process, will guide your mind and heart in the right direction.The Answer"Just Enough to Make the Project Successful"
I realize this answer seems like an evasive maneuver to a complex question but there isn't necessarily a heuristic or rule of thumb to answer this question. When considering the answer you must consider several factors:1) The size and scope of the project
2) The amount of inherent risk associated with the project3) The methodology by which execution of the project will be undertaken
4) Other softer attributes that may be specific to your company or the project itself
Size and Scope of a ProjectGenerally speaking, the greater the size and scope of a project, the more discipline(s) necessary to continue to drive successful delivery.
This is not necessarily always true, but generally speaking, one would exercise more discipline in higher risk situations and larger projects can tend to be higher risk situations. They require more people, more money, longer timeframes, more departments, and can be higher visibility, than smaller projects. All of these elements introduce higher levels of risk which, in turn, must be managed diligently.The Amount of Inherent Risk Associated With the Project
I wrote a great deal about risk in the earlier paragraph so I won't go into it again here. I will say though, that larger projects generally require greater attention to risk management than smaller projects. It is true that you could have a very high risk project of smaller scope or duration, but smaller projects won't necessarily get the same risk planning and mitigation treatment as larger projects. Think about it; are you going to spend as much time in mitigating risk on a project as you would on the entire project? Probably not.The Methodology by Which Execution of the Project Will be Undertaken
When I write this, I am speaking specifically to Software Engineering projects. What I mean is this: If you, the Project Manager, have enough understanding of how the product or service will be delivered by development staff, then you may choose to make certain important decisions about which Project Assets are most valuable.For example, say you are involved in a Software Engineering project and you find out that the development team will be using an agile methodology such as XP or SCRUM to develop the software. You know that the tenets of agile software development are fast turnaround, constant requirements and technical discovery, and frequent test and release intervals.
Knowing that there are elements of "constant requirements and technical discovery" you may choose to use a thick and more rigid Change Control process to ensure timely delivery.I am sure that you can think of many more examples.
Other Softer Attributes That May be Specific to Your Company or the Project ItselfThis pretty much covers all other aspects of the project such as corporate culture, project intricacies, product cycles, politics, and any other factors that may play a role in how you drive execution.
It is safe to say that you will need to customize a list of project governance assets for almost every company you are part of.Using Dollar Amounts to Guide Your Project
Some companies set thresholds on how much governance or structure one must place around any given project. They generally do so by dollar amount and set a threshold so that any project over $X million gets XX Project Management disciplines.I recommend against this though and here's why: The amount of money you must spend in order to complete a project is simply not a measure in itself of how much structure the project will require. You must take into consideration a multitude of factors when making this decision and money is only one of those factors.
In ClosingI feel that an agile set of baseline assets and practices for ALL projects is the best approach. Meaning this: draft up a few "must have" assets and activities that must be undertaken for all projects and then build on top of those for larger or more complex projects.
For example, you may choose to always require a Project Charter, Risk Assessment, and Change Management process, but may only employ a full Project Review on certain projects. You will also choose to undertake the baseline set of assets and activities to differing degrees depending on the size of the project as well. There will always be a Project Charter but it will not always be multi-page. Sometimes, it will only be a half-page depending on the project.I think you get the idea. We are here for project success, not simply to provide a process which project team members must follow. At the end of the day, it is a bout the product or service delivery, NOT about the process and it is always important to ask yourself if you're helping the project along or potentially hurting it with thicker processes.
Jason Becker, PMP, CPM
]]>Sure, with enough Fairy Dust and some wishful thinking, anyone can make a Worldclass Software Engineer or a Pipefitter, or a Chemical Engineer out of Fairy Dust too, right? You Can't? Then why are Project Managers different?
We all know I am simply making a point here and that is that the role of PM is often minimized in the minds of those contemplating the notion. For some reason, when some people think of a Project manager, they think of someone that simply manages a task list in a scheduling tool, or someone we only see when we've overrun our budget.
This in itself has been the cause of many project failures.
]]> Drive-By PM'ing The role of Project Manager is often bestowed upon an unwitting and untrained member of a team (I call this a drive-by PM'ing) such as a Software Engineer, Business Analyst, or Requirements Engineer.All too often, a decision maker considers Project Management as a discipline and decides to make one of his/her Superstar Engineers responsible for the Project Management activities on a project. This is perilous because the scope of proper Project Management has been underestimated from the starting-line and the project will suffer two (or even three) fold due to the geometric equation of taking your top resource and time-slicing with them.
There are a plethora of afflictions associated with this problem that can be discussed in a later post.Recognize
Not to say that a Business Analyst or a Software Engineer cannot make excellent Project Managers. It will require training, it will require time, and to be good at it, it will require experience. Not at all unlike the way in which the same Business Analyst or Software Engineer came upon their current skillset. Recognizing that PM skills are necessary is a huge step but what we need to do from there is educate ourselves and those around us about what Project Management is and what it isn't. Making sure people have broken free from the ideas that Project Management skills simply slow us down or prevent us from making progress is a good start. Project Managers are here for project success and no other reason, lest we forget.
In ClosingThere are many resources available for those wishing to make a leap into Project Management but it is best to think of PM skills as a broad portfolio of skills, most of which are somewhat counter-intuitive, and most of which are softer in nature and are difficult to teach and learn. I suggest formal academic training combined with real-world project work as a good combination for knowledge retention and true learning.
If you could use Fairy Dust to make Project Managers, then you could probaby use it to fix broken projects too.
Jason Becker, PMP, CPM
]]>