I love deadlines; I especially like the SWOOSHING sound they make as they fly past
— Douglas Adams
Deadlines are made after the work needed to meet the deadline is defined and the appropriate schedule, cost, and resource utilization margins have been discovered. These values must be worked from right to left if the deadline has already been fixed.
This will tell you when you should have started the project. The process of defining he needed schedule margin is provided by a Monte Carlo Simulator tool. My favorite is Risk+. This tool prouces confidence levels for completing "on or before" a specified date. With a "zero slack" schedule, Risk+ can tell the probabilistic completion date to a level of confidence. 80% confidence of completing "on or before" is a good number. The gap between your "zero slack" date and the 80% is the needed margin for the "zero slack" schedule.
The next issue is where to put that schedule margin. That's another topic.
Ron Rosenhead provides a great post about the organizational sources of project failure.
There are of course other sources of organizational failure modes, but Ron's list is a great starting point.
Bill Mathis on LinkedIn Earned Value Management and Paul Solomon both posted news of the GAO released a report on the need to improve the application of Earned Value to manage major acquisitions. Defense was the only agency with "all black," except for training.
From the introduction:
Given the size and significance of the government’s investment in IT, it is important that projects be managed effectively to ensure that public resources are wisely invested. Effectively managing projects entails, among other things, pulling together essential cost, schedule, and technical information in a meaningful, coherent fashion so that managers have an accurate view of the program’s development status. Without meaningful and coherent cost and schedule information, program managers can have a distorted view of a program’s status and risks.
Note that any solution to the "problem" of project management needs to "pull together cost, schedule, and technical (performance) information"
Try that with your email based, IM, twitter, Face Book, social networking PM 2.0 project management system on anything other than a toy project and see how fast you can get into the ditch.
Pretending for the moment that we are over the issue that 2.0 processes do not start with 2.0 tools, Kailash Awati has a good post on on Post Bureaucratic Organizations.
The discussion here is how to manage projects in the absence of full command and control. This new paradigm is present in the Integrated Product Team (IPT) environment. An IPT project is a multidisciplinary group of people who are collectively responsible for delivering a defined product or process.
In these environments collaboration and "flattened" organizations are comment. IPT are mandated by DoD and DOE contracts. We're working a $100M DOE CO2 sequestration project where 3 major players are sharing the preliminary design and validation of the power plant. The Project Management Plan (PMP) describes the interaction between all the IPT's and how they will collaborate at the top level to assure the project reaches its "done" state.
Here's a possible repositioning of the PM 2.0 topic.Not favorable to the PM 2.0 tools vendors, but focused on the project management processes first.
Project Managers need to know a few core items:
Without the answers to these questions in the affirmative every period of measurement (weekly is best), no amount of 2.0-anything is going to help the project stay on schedule, on cost, on specification. PM 2.0 at best is a mechanism to improve the operational processes once these questions have been answered.
Inverting the approach of having PM 2.0 and Web 2.0 be the starting point is a formula for failure on all but the most trivial of projects. By trivial I mean if the project fails no one loses their job.
For all projects where someone will lose their job if success is not reached, the tools are 2nd order at best and likely 3rd order impact on success. Many firms we work with have 10's of millions of $'s of tools - even 2.0 tools - and still fail to deliver within the boundaries of budget and schedule.it ain't the tools...it's the process and people executing the processes.
Tools are a distant 3rd
The discussion on a semi-commercial blog (a blog hosted by a product based company) presents the notion that PM 2.0 enabled by Web 2.0. While a pretty good start at a marketing campaign for the product, the critical missing element is "what does a project manager do when she is doing project management?"
Here's a sample of previous advice.
Now the thread here is that the processes of project management are pretty much independent of the tools used to implement those process. Oh yes, Web 2.0 tools can improve the visibility, possibly increase the cohesion between the team members.
But can these tools make these improvement in the absence of the proper execution of the core processes of project management?
I'd say from personal experience and the experience of our staff, the answer is a resounding NO. We have clients that have invested 10's of millions of dollars in tools and still are OTB (Over Target Baseline). They're in the ditch despite the investment in tools - many time in the current collaborative tools.
Tools "may" be necessary for project success, by they are far from sufficient to success. Core project management process are little changed since the advent of modern practices built around earned value and program risk (probabilistic risk).Even the supposed "agile" project management practices, follow the core processes of project management
Pick what every tool works for you.
DO NOT start with the tool. Start with the working process, back into the tool. Ignore all the sales pitches that tools solve the problem. They do not.
An Example of Project Management
Just to close out notion of project management, here's a sample job description from a local Denver company. This is typical of the types of project management roles, where tools are secondary to the project processes.
Minimum 15 years Project Manager or related project experience managing large VA hospital programs in excess of $500 million. A Bachelors degree in Engineering, Architecture, or Construction Management is required, with an advanced degree and professional license preferred. Must be proficient with Microsoft Office applications to include Word and Excel, as well as knowledge of construction scheduling software. Excellent written and verbal communication skills necessary.
Craig Brown pointed out the Harvard MBA Oath
Josh had a question awhile back about the usefulness of an MBA. This oath would be a good starting point for defining the "value of an MBA." One of Josh's Blog contributors stated how abhorrent it is to have MBA's running projects. This is one of the typical nonsense statements made out of context and divorced of any domain.
As a holder of an MBA - not from Harvard, USC - go Trojans - I can say with unabashed enthusiasm, that going through an MBA program having started from a graduate degree in physics. Learning where your pay check comes from, how the place the pays you makes money, and all other financial, marketing, and accounting processes cause this money to appear.
As a project manager, this knowledge is critical to a project's success. Possessing this knowledge allows the PM to be directly connected with business and the business case for the project - at least in the commercial world.
The US Department of Energy has project management resources that are generally applicable to a variety of domains and contexts.
The DOE Office of Project Assessment is the entry point for many things "project."
The DOE Series O 413 is an overarching set of guidelines for project management including IT projects.
Craig Brown posted this video, as other will certainty do in the agile community
From the Cognitive Edge.
The point of emergence (for social activities) is very important. Our firm is "emerging" to the next level of revenue and processes that support that revenue.
However, is this paradigm appropriate for projects and the management of projects:
Let's ask the question of this paradigm?
What class of projects in the commercial or government world (projects using someone elses money) would be appropriate for the emergent process described in the 3rd of the 3 options?
This video has hit a home run with me. The answer to the question above need to be in place before the word emergent can be used with the word project.
Several Blog posts this week speak to the softer side of project management, leadership of projects, and guiding the staff of a project. Eugion's PM Workshop Blog has several good posts around this topic. His blog has been improving with every post since I discovered it earlier this year.
I'd like to speak a bit about the flip side of the "softer side." First the principles of project management in our domain. This domain - at least the domain I'm accountable for in our form - includes aerospace and defense program planning and controls and civil and commercial government projects. Commercial government projects are executed by recipients of government money - usually federal and state funds.
In this domain we apply our Deliverables Based Planningsm method in its full glory. This means:
In simple terms - tell me what you're going to do, do it, and tell me what you did on a weekly basis. This weekly Plan of the Week (PoW), is guided by the Plan of the Month (PoM). This Plan is of course guided by the Statement of Work (SOW). The result of all this "planning" is that everyone - the client, the stakeholders, the participants, and especially the project manager and the subject matter experts from our firm know what DONE looks like at the end of every week. On some projects or programs we also have a Plan of the Day. Just like eXtreme Programming - what a concept.
So now comes the "softer side" of managing projects. There is a minimal set of human behaviors on our projects. Professionalism of course. Recognition of subject matter expertise. We don't have any junior position. We're too small to hire people who need training. 10 to 15 years PM, PMP, core business skills.
But what drives all this is a critical success factor for all the project and programs we work.
Define what done looks like, then deliver to that description
What happens when that doesn't happen?
What happens when the deliverables don't show up on time? The first thing is that "not showing up on time" is crystal clear on the Monday after the Close of Business (COB) of Friday. The status for those deliverables is now YELLOW at least and possibly RED.
You didn't do what you said you were going to do. Hal Macomber's Securing Reliable Promises is a good example of how to apply Deliverables Based Planningsm.
When the deliverables for the week don't show there are several steps that must be taken:
Now what happens if the "late" behavior repeats? Is it the person, the process, the environment, the client, the technology. This is now where Eugino's conversations start. But in a way possibly different than he intended.
The Project Manager or the Site Manager must rapidly determine what the root cause of "lateness" is. And make a change to "keep the project GREEN." If not the project will head for the ditch. The softer side of project manager has limited benefit in the presence of a Late project. Especially when the project staff is senior. Junior members need more "softer side" management. Senior members are on the job because they are senior - they know better. Or at least they should know better.
In The End Its the Deliverables That Matter
All the softer side process are needed for success - less so for senior members. But in the end the client did not buy self actualization and staff development for external projects. They bough a solution. This is a critical different between internal and external projects.
This BTW is why construction project managers are continually cranky. They're usually late and over budget all the time. And if not, they've spent huge amounts of time and energy keeping the project on schedule and on budget - and they're tired and cranky from just doing their job.
I've never met a Aerospace or Defense program manager that had a smile.
Progress can be made by
Ares I-X Flew Today
The flight avionics of the manned spacecraft portion is one of the programs our firm works as Program Planning and Controls personnel.
The commitments needed to meet a launch date, is a culture embedded in the manned space flight and launch vehicle business. These commitments start with a clear and concise description of what "done" looks like, the accomplishments needed to produce "done," and the criteria by which these accomplishments will be judged.
Add to this the continuous risk managPublishement process for every step, every week, every deliverable.
“Opinion is the medium between knowledge and ignorance.” — Plato
Josh pointed me to a post on CIO.com titled The 10 Key Capabilities of Next Generation Managers. Like all good strawman arguments, it's with a statement of the obvious
...shifting business conditions are changing the role of the project manager and the skills associated with it. "Organizations are striving to achieve faster [software] delivery without diminishing quality or increasing cost," she writes. As a result, she observes, they're moving from traditional software development methodologies to more Agile ones.
Really why agile? Getting faster, without diminishing quality and increasing cost is certainly desirable. By why does agile provide this? Is there evidence that agile does provide this? If so in what context and in what business domain?
I have personal experience and samples of others personal experience that agile provides faster response time and sometimes better quality in the "continuous maintenance mode" of commercial IT. PayPal is a good example.
What about standing up SAP or Peoplesoft in a distributed corporate environment? How about developing 21CFR compliant medical software from scratch. Or my favorite, developing and installing flight avionics upgraded to helicopters in the field?
The next classic strawman argument is...
The move to Agile software development "shifts the role of the project manager from a director to a facilitator," writes Gerush, because Agile development methodologies rely on self-managed, cross-functional teams.
Self organized, sure. Self managed. Would the project manager for Chase look forward to self managed teams during the move this week from www.wamu.com to www.chase.com. All my accounts came over no problem. All bill pay history moved. It was a seamless transition from the point of view of the customer. Self managed? I'd be dumbstruck if the teams managed themselves. Self organized? Possibly.
As organizations realize that traditional software delivery methods are bloated with processes and artifacts that add little or no value, they are trending toward Lean Software—and this transition will significantly change how they deliver projects, writes Gerush.
How about a single example? "Little or no value" to whom? SOX compliance be dammed. ARRA reporting through CFR 600 be dammed. ITIL compliance for corporate computing - we don't need that.
"Processes and artifacts, we don't need no stinkin artifacts."
Come on Ms. Gerush, provide some context and domain here. This is pure nonsense in the absence of a business domain and development context.
As companies distribute their software development around the world, the project manager's ability to communicate with and relate to people from different cultures becomes even more important.
When was this not important, even in the same room? A nice tautological argument.
Project managers also need to be more focused on business value.
When did "real" project managers NOT focus on business value. This business value by the way, must be defined by the business owner not the project manager. This business value in held in the business case, which should be derived from the business strategy (Balanced Scorecard is a good starting point), which defined the needed business capabilities. The PM's job is and always was to deliver that business value from the project in terms of requirements fulfilled.
Ms. Gerush's 10 Key Capabilities include:
This is one of those lists where you've forgotten what the point is and agree with the content. This links the initial poorly formed these with an undeniable outcome. The way out of the "false premise" argument approach" which is a good car sales approach as well - is to invert the argument.
Do you want a project manager that has poor emotional intelligence, is a crappy communicator, stinks at people skills, has poor management skills, is inflexible, has no business savvy, no analytical skills, hates customer, never delivers on anything, is missing core charter?
I know of no one on the planet who would want to hire such a project manager. So what's the point? There is no point. It's the restatement of the obvious in the absence of context and domain. An unassailable argument that is then bridged to "agile."
This kind of stuff wouldn't get a D in the high school forensics class (many types of debate, poetry, and drama). We desire a better assessment of the problem of managing corporate IT projects. Forget the $400 price tag. Look to working project management process in industries you work in.
What to see the basis of complete disaster for corporate IT? Follow this advice.
Notably, technical- and traditional project management skills are absent from Forrester's list of core capabilities for next generation project managers, but not because those skills are no longer necessary. While those skills remain important, Forrester maintains that because the softer skills are more difficult to learn than hard project management skills, organizations may be better off hiring individuals who are strong in those key capabilities "even if they lack experience in accepted project management practices."
I can just see it. The PM has all those softer skills, has character, is flexible, business savvy, etc. But is completely clueless about the effort and risks involved with integrating SAP with PeopleClick for FAR 35.1 compliant time reporting in the ARRA grant management business. Eveyone on the project is self actualized, informed, communicated with and holds the highest integrity in their dealing - but the !@#$ing system doesn't work on the needed "go live" date for the monthly report and the DCMA sends a nasty letter that they'll be on site for next months reporting process audit. Oh yea, we're modern project managers now.
Principles that are established should be viewed as flexible, capable of adaptation to every need. It is the manager’s job to know how to make use of them, which is a difficult art requiring intelligence, experience, decisiveness and, most important, a sense of proportion.
– Henri Fayol, General & Industrial Management
Leadership is all the current rage in project management circles. Courses on project leadership. Forums and Blogs on how to "lead" a project.
Leadership is the articulation of vision, organizational vectoring (direction and velocity), and the creation of a business environment for fulfillment of these "goals." Management, which is now subservient to the leadership discussion, is the orchestrating of the production objectives to fulfill these objectives.
Much of the scholarship and writing about leadership comes from people have never led or managed anything other than in the classroom or in their book on leadership. In much of this leadership literature, management is at best ignored and worst disparaged as a hurdle to project success. The basic "blocking and tackling" skills of project management are skipped over for the higher goal of "leadership."
Many failing projects have crippled management processes. The Knowledge Areas of PMBOK are missing. The measures of physical percent complete are absence. Risk management is nonexistent.
The source of many of the project performance problems is poor leadership. The synchronization between leaders and managers is missing. This unity of effort toward a common goal is the first requisite for project success. The false notion that "leaders" can replace "managers" is misguided at best and disastrous at worse.
Both leadership and management are required for success. The common approach of flattening the organization has led to the removal of "management" and the insertion of a "Leader" and a collection of followers. Or - another false notion - a collection of "leaders" in a self directed team. Not a self organized team, a self directed team.
If increasing the probability of project success is the goal of Project Management, the MANAGEMENT role must be present as well as the LEADERSHIP of the project.
With poor accuracy control . . . various stages of production can be churning out ‘on time’ (but dimensionally varying) intermediate products. Every process is indeed meeting its schedule, and everyone is happy. Then when it comes to final assembly (late in the programme), all of a sudden things just don’t fit together and all sorts of time-consuming, handcrafted rework must be done. There goes the schedule.
- Rand Report - Monitoring the Progress of Shipbuilding Programme, MG 23.
Possessing a 1.0 measure on CPI and SPI is necessary but not sufficient for program success. Delivering all the parts on time and on schedule is necessary but not sufficient for project success.
For project success all the moving parts have to come together with the correct behaviors at the right time and with the right cost.
In the end ALL the pieces of the product have to both come together as individual pieces and come together as a system for the project to be successful. This appears to be obvious, but seems to be harder than it looks.
How can we "see" into how these pieces all come together - an Integrated Master Plan and Integrated Master Schedule.
PMI just announced a new publication Project Management Circa 2025. What a great idea. Something to read and contemplate when mired in the details of getting a "bad" project back on baseline in the middle of the night.
But wait, the long awaited tome is $39 for members. $49 for non-members.
Sorry, this is a non starter for me. I'm a loyal member of PMI, speak at PMI conferences, support the local chapter, past co-director of the A&D SIG for Region 6. All that good stuff. But something that is a direct benefit to the practice needs a free summary to see if I'm even interested in spending my $39.
The processes needed to increase the probability of a project's success include:
Things fail when they are not taken seriously, things work when they are respected and effort is applied to them.
- David Green, Department of Ageing, Disability and Home Care, New South Wales, Australia
When you hear someone say "we tried that and it didn't work," you need to be skeptical until you've verified that the person making the statement was actually qualified to make it work.
Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.
— Charles Tremper
Developing effective plans, be they risk, project, cost, capabilities, or operational is a critical success factor for any project. In the absence of a credible plan, the project takes any path needed to get to the end. Irregardless if it is the right path or not.
When presented with a 2.0-anything, ask — why is this better than what I've got working now?
If the answer is in anything other than bookable time, money, product performance measures that are statistically significant — no wimpy 10% to 20% increases — hang up.
You need 200% increases to migrate from a well run system to something. New. You need 100% increases to migrate from an OK system to something. If you have system that is below OK, fix it first for free.