An interesting paper in the September edition of the Project Management Journal co-authored by a colleague, Derek Walker contrasts the delivery of public projects in the Roman era with modern project management. The primary conclusion is that nothing much has changed; the Romans outsourced most of their major works to contractors, with both public accountability and a legal framework as key governance constraints.
What’s significantly different, is the consequences of failure! If a project went badly wrong in Roman times, the responsible public official would suffer a major career limiting event that could affect the prospects of his descendants for generations to come. Whilst the retribution applied to the contractor could be even more serious including death as well as retribution for generations to come.
Applying the Roman approach could give a whole new meaning to the ‘pain share’ bit of an Alliance contract…… as well as removing by execution many of the worst performing contractors. Rome was not built in a day but their empire did last for close to 1000 years.
This history contrasts with several recent studies that clearly demonstrate the ineffectiveness of penalty clauses as a mechanism for managing client risk two relevant papers are:
CIOB; Managing the Risk of Delayed Completion in the 21st Century
Blake Dawson; Scope of Improvement
It would seem the sanctions offered under today’s laws are insufficient to make penalties really effective (and in modern contracts they only work one way rather than the two-way effect of the Roman sanctions). Therefore the only option is proactive management.
The unacceptable alternative is to hope the problem goes away…… but burying your head in the sand leaves a very tempting target for someone’s boot.
If you are interested in the history of project management, my papers offer a good starting point, starting with The Origins of Modern Project Management at: http://www.mosaicprojects.com.au/Resources_Papers_050.html
For more in-depth coverage see: http://www.lessons-from-history.com and of course: Frontinus – A Project Manager from the Roman Empire Era by Walker & Dart (Project Management Journal Vol.42, No.5, 4-16)
« Minimum Concepts for Earned Value Management | Main
August 03, 2010
Quote of the Day
“When a program agrees to spend less money or accelerate a schedule beyond what the engineers and program managers think is reasonable, a small amount of overall risk is added. These little pieces of risk add up until managers are no longer aware of the total program risk, and are, in fact, gambling. Little by little, NASA was accepting more and more risk in order to stay on schedule.”
‒ Columbia Accident Investigation Board Report, 2003
When we speak about risk management, here's a reminder of the consequences of not addressing risk
Risk Analysis: Avoiding Future Impacts, INCOSE Heartland Chapter, 2001
Posted by Glen B. Alleman on August 03, 2010 at 02:24 PM | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341ca4d953ef0133f2d3913f970bListed below are links to weblogs that reference Quote of the Day:
Comments
Advising Upwards
June 9, 2010 · Leave a Comment
Your project will only be considered successful if its key stakeholders perceive the project’s outcome as a success. These perceptions of success or failure are heavily influenced by the effectiveness of the project’s communications, and relationships, with its stakeholder community, particularly senior managers. Communicating effectively is both a science and an art framed within a relationship.
The starting point if you wish to be taken seriously is to develop a reputation for credibility. Senior management need to recognise that if you say something, it is backed up by facts, and if you commit to something, it is delivered. Credibility is earned by performance, but there is no harm in quietly making sure your performance is noticed in the right places. Your reputation is a general underpinning to all internal organisational relationships. Developing a specific relationship needs a specific, culturally appropriate focus before you can expect to communicate effectively.
Also, the last few years have seen significant changes in people’s understanding of acceptable behaviours and have forced a re-evaluation of the way Project and Program managers need to communicate to influence their stakeholders; particularly when ‘advising upwards’ and dealing with difficult people. The first key to building any effective relationship is to avoid stereotyping. Upwardly mobile managers with a focus on being promoted, frequently have a different life focus to project managers. These differences are not uncommon in successful senior executives and need to be respected as a component in the relationship, not denigrated.
The second key is to recognise that in every relationship there is a power dimension. How a senior manager uses his or her power is to an extent a generational issue. As long as they understand their purpose, many younger managers would see nothing wrong in a more junior manager setting reasonable boundaries and procedures to the relationship and communication. Older managers used to operating in a command and control environment are likely to react negatively to a ‘junior’ pushing rules upwards.
The solution is mutuality. You need to understand what you need from the relationship (support, resources, backing) and also what the senior manager needs from the relationship. Then, work within the relationship to negotiate mutually beneficial outcomes that meet both sets of requirements. It is by linking your needs to the achievement of the senior manager’s requirements; you can start to achieve real communication.
As already mentioned, crafting advice to senior management to achieve effective outcomes from the communication is as much an art as a science. Communicating for effect requires a clear understanding of the objective of the communication and the skills to create messages that are focused:
- On the right people
- At the right time and carry
- The right information in the right format.
Mutuality and credibility are the two keys to advising upwards, but in the end, all relationships depend on the situation. If you are seen as a serious contributor to the organization’s success and can link your needs to the needs of senior management, there’s a high probability of achieving your desired outcome and benefiting the organization at the same time.
My next book, Advising Upwards: A Framework for Understanding and Engaging Senior Management Stakeholders, will be published by Gower in 2011. For more on the book see: http://www.mosaicprojects.com.au/Books.html#AdvisingUpwards
In the meantime, our popular workshop, The science and art of communicating effectively will be run in Sydney and Melbourne over the next few weeks. For more information see: http://www.mosaicprojects.com.au/Training-Comms.html
Categories: Stakeholder Management
Tagged: Project Management, Stakeholder Management, Communication, Stakeholders, Project success, Project, Relationship Management, Advising Upwards
I am amazed by the number of project management commentators who flatly refuse to recognise that risk = uncertainty that matters and that uncertainty can be positive or negative (ie, it’s uncertain).
The latest commentator in a long line of negative thinkers is Michael Hatfield in PMI’s Voices on Project Management blog. His approach to risk suggested in ‘PMBOK® Guide for the Trenches, Part 4: Risk’ is simplistic and assumes all uncertainties are negative…..
There are numerous problems with this simplistic view of the world:
- Firstly the same risk – a future uncertainty – can have both an upside and a downside. Failing to manage the upside equates to guaranteeing failure (or at least missing opportunities).
- Future weather conditions are a risk; they could be good or bad. A major motorway near my home town was finished months early and under budget because they were lucky enough to build the project at the tail end of a 10 year drought. The last few months have had above average rain. If the people building the road only worried about the ‘downside’ risk the road would only just be finishing now.
- A similar example is the management actions taken to accelerate work on the Panama Canal through the GFC to take advantage of then upside risk of lower construction costs.
- Second, the environment around projects does not stop changing just because someone has signed off a cost performance baseline. Ongoing risk assessments are critical to avoid surprises; good or bad! The more warning of changed circumstances the project team have the more likely they are to manage the situation effectively.
One of our key areas of expertises is stakeholder management – each stakeholder can be a threat to the project if badly managed and a supporter if well managed. The Stakeholder Circle® methodology has been explicitly developed to first prioritise stakeholders then focus on the important high priority stakeholders to achieve an optimal level of support to allow the project to succeed (for more see http://www.stakeholder-management.com/)
Where we do agree with Michael is on the mumbo jumbo of statistical paralysis many so called risk management systems bog down in. The purpose of risk management is to identify opportunities and threats and then actually do something about them. Recording risks in a risk register and then qualitatively and quantitatively analysing them is a complete and total waste of time unless someone actually takes action. This is the focus of our ‘How To’ build a Risk Management Plan workshop – yes we have a cute Excel risk register but the purpose is action not documentation.
The biggest weakness in the current version of the PMBOK® Guide is the total omission of a process for treating risks. The idea of risk treatment is implied, but not overtly set out as a process, which allows people to think identification and analysis is the end game. Unfortunately managers need to make decisions based on the risk assessment and then take actions if risk management is going to deliver any benefits at all. Hopefully the 5th Edition will fix this.
Possibly related posts: (automatically generated)
« The Language of Projects | Main | Another Version of "What Does DONE Look Like" »
April 20, 2010
Knowing What DONE Looks Like
I'm finishing off 4 briefings for the 2010 EVM World in Naples Florida in June. The theme of these briefings of "connecting the dots" between Cost, Schedule, and Technical Performance Measures.
I finished one of three of my briefings and course work. Behind schedule !!
It dawned in me that there are a simple set of phrases that describe the basis of program success. Program success means...
Without these four elements you don’t have a clue to what DONE looks like or if you’ll ever get there as planned.
- Knowing what DONE looks like begins with the Integrated Master Plan.
- Recognizing what DONE looks like when it arrives means measuring the planned Technical Performance.
- Measuring Physical Percent Complete tells us how far we have moved toward DONE by calculating the “Earned Value” we’ve achieved.
- Connecting Earned Value, Technical Performance, and Physical Percent Complete establishes a credible measure of Progress to Plan.
I'd conjecture this is the source of most of the cause of project failures, in the IT business as well as the defense business. Forget all those methodologies, esoteric discussions of this method of that. If you can't answer these questions in some credible manner - you're hosed. No method is going to save you.
Posted by Glen B. Alleman on April 20, 2010 at 10:28 PM in Management | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341ca4d953ef01348004c997970cListed below are links to weblogs that reference Knowing What DONE Looks Like:
Comments
The Getting Things Done (GTD) productivity system has a place for everything, but you have to know where everything should go. Lifehacker alumnus Kyle Pott tweeted a checklist from GTD founder David Allen that helps determine where that just-arrived email belongs.
A reference sheet Allen sent out in his newsletter, graciously posted to Kyle’s site, uses plain language to help you narrow down what you’re thinking about something (“I might want to commit to this at any time in the future”) and tells you where that should go in a prim-and-proper GTD system (Someday/Maybe list item). Not everybody practices canonical GTD, as with Gina’s simplified GTD, but this list helps you determine, at least, where any item or document should go in a fully realised productivity setup.
GTD Checklist [Kyle Pott]
Many years ago I had the pleasure of working for a brilliant man. One of many, actually, but this man in particular had some of the best lessons for me in terms of managing people that I’ve ever learned.
He hired me to manage a portfolio of trading applications on an enterprise backbone. I had no experience with that in particular and one day I asked him why he hired me.
“Papa Joe’s,” he said. I looked at him askance, remembering a bar I used to hang out at in downtown Singapore. About five years prior he’d visited Singapore and I took him out on the town, as was my way with visitors.
I asked him what that had to do with anything.
He replied, “I was wearing sandals and the rude woman at the door wouldn’t let me in, so you kicked up a big fuss on my behalf. You didn’t have to do that.”
Rather perplexed by the complete non-sequitur, I asked again what on earth that had to do with trading applications.
He said, “nothing. But I’ve gone through three Vice Presidents who haven’t had the chops for this job. The business just runs all over them. Some people can have all the best technical skills, or domain knowledge in the world: if they can’t do a simple thing like stick up for someone or something they believe is in the right, they can’t handle this environment.”
Incidentally in that particular job, the head of the business (who was a tough woman to please) commented that she was glad she finally saw the teams working together to solve problems; something she hadn’t seen at all since the inception of the portfolio.Stick up for something you believe in. It won't kill you.
I’ve thought about that often. It’s not like I brought anything special to the table in terms of knowledge or insight. My teams working for me knew way more than I did in their respective areas. How did the fact that I publicly stood up for people help my work at all?
Well, when I watch people in meetings stick their necks out, I am often very surprised at the number of people who will say nothing. Quite likely they’re afraid of taking a position others will find controversial. They may be afraid of being seen on the wrong side of the fence. But here’s my take on what I believe happens:
1) Team members stick their necks out. Frequently in person, although not always. Nobody bothers to support them and they’re left to fend for themselves.
2) Trust breaks down. Why would someone take a position they know others agree with when they will only be cut down by those who don’t?
3) Teams stop collaborating. There’s no point finding out whether or not people will agree with you if nobody will support you when it counts.
4) New ideas stop coming. If people aren’t collaborating, there’s no synergy to spark new ideas or problem solve.
5) Operations become purely reactive. If people aren’t problem solving, they’re certainly not looking ahead. They become stagnant and reactive, only dealing with problems after they’ve happened.
6) Client organizations become very unhappy. You see how that can happen?
I’m not saying that this is the only cause for apathy in the workplace, but it certainly happens a lot. Frequently if I’m not in charge, I’m the one to cast my yay or nay vote in a meeting because I can’t stand to watch someone publicly suffer and stand on the sidelines.Have you seen this in your workplace?
When a work environment becomes apathetic (and oh, so many of them are), where is the joy that comes from working and doing a good job? What’s the point of getting up every morning to go to a grind you don’t care about? Surely there must be more to life than that.
But who’s responsible for creating that culture? Well, from my perspective everyone is responsible for it. In much the same way as Code Name: V claimed the people of London were responsible for the totalitarian conditions in which they found themselves in the outstanding film / graphic novel “V for Vendetta”. But as he went on to claim, “some are more responsible than others”. As a manager of people, and the head of an organization, no matter how large or small, you are responsible for the culture you foster in the workplace.
That means, even if you work for a company whose senior management doesn’t care about corporate culture, you are still responsible for the development of corporate culture immediately around and below you. True, you could make it someone else’s problem, but like Code Name: V also said, “an idea can change the world”. If you step up to the plate, you may allow one of those ideas to grow and thrive…and won’t that be worth the risk?
Control Your Email Inbox with Three Folders
February 2, 2010 at 9:01 amby Gina Trapani
I'm thrilled to announced a new series of weekly videos and blog posts that I'll be publishing at FastCompany.com called "Work Smart," which will cover personal productivity in a digital world. Long-time Lifehacker readers will recognize much of the material, but some fantastic editing and animation make each 2-4 minute video segment a whole new, fun format. The debut Work Smart video segment takes on the age old digital productivity problem: email overload.
In this 2 minute, 45 second segment, I describe my three-folder system for emptying your email inbox on a day-to-day basis, and keeping on top of everything you have to do, are waiting for, or want to keep on hand for reference.
I first wrote about this three-folder system on Lifehacker back in 2006 as a riff on Merlin Mann's five-folder system, which he published in Macworld in 2005. Of course, Merlin went on to be the king of Inbox Zero (book forthcoming!). For a much longer--and much funnier and in-depth--video on using email well, check out Merlin's hour-long Google talk about it.
I've been using this system to organize my email since I wrote the original article back in 2006, and I've found it's an absolute sanity-saver. At this point it's so ingrained in my workflow I barely think about it. Though I must admit: some weeks I'm better about it than others. This week I'm on book deadline, and I do have about 40 messages that need to be processed sitting in my inbox right now.
This video segment is the first thing I've ever shot in a studio with a backdrop, lighting, a director, sound guy, two cameras, makeup artist, and an actual script. Besides that weird thing my hair is doing, I'm so pleased to see what came out of what felt like 600 takes. Our editor and animation artist, Adam Barenblat, did an incredible job of turning a dry, boring, "create this folder and name it this" subject into something really fun to watch. Thanks a whole lot to FastCompany.com for having me, and for the crew at Magic Bullet Media for turning out something so cool. There will be a new video every week for the next few months at FastCompany.com, and I'll post about each new one as it gets released here as well.
If video's not your thing, here's the transcript of the segment.
Filed under Workflow
2 comments-->
Love the look of the video and the tips for organizing my email overload will be invaluable. I am going to start today on implementing these tips into my workflow. A great start to this series and I can’t wait to see what other videos and topics will be discussed.
Nice video, definitely looks like a helpful system. The 605 items in my inbox suggest I need to try this out!
One side note…the angle you’re looking away from the camera is a little awkward for the viewer. It’s far enough away that I feel like I’m eavesdropping on a conversation I’m not a part of.
Anyway…looking forward to seeing more of these. Subscribed
One simple step to better configuration management
Tuesday, 26 January 2010Many say that configuration management is hard. It is. 100% correct, "as the books says" software configuration management is hard. It takes tools, skills, discipline and effort to build and support reliable and effective software configuration management process. It is especially difficult, when there is already some process in place and improvement involves change.
My experience shows that it is particularly challenging when it comes to non-source code items like documentation and release packages. Can you imagine following dialogs with project team members? I can…
Managing source code:
--Is it necessary to follow Configuration Management practices, when you work with the source code?
--Yes!--Do you use source code control system during development?
--Sure!--Would you start coding without SCC in place?
--Absolutely not!Managing release packages:
--Should you manage configurations for you release packages?
--Oh, yes!--The best way to do that is to be able to recreate any version of release package...
--Oh, yeah! That's the best way, especially, if you hook this up to automated builds and tests...--Do you do that?
--Well... You know, that requires time to setup. We are so busy with other tasks actually writing software, so we never actually got to that... And, by the way, our existing process is not that bad...--But still you can get all the previous release packages, right?
--Well, I guess so... We have a share where all the releases are uploaded.--Do you delete files from there?
--I think so. When we need to.Managing documentation:
--Should you keep track of the versions of all the development-related documents that you've got?
--Yes, definitely!--So you do that, right?
--Well... Not exactly... You know SharePoint (or another tool, you name it) is somewhat difficult to use (or setup). We just put the file in a shared folder or sync over the e-mail. When the document is final, we put it into SharePoint.--I see... But you do change version number on the document each time you edit and keep it somewhere, don't you?
--No, not really. Do we need to?..Generally, the further you get from the source code the worse it gets.
There is a simple, not ideal, but simple remedy to this, which lies in mimicking what source code control system does:
Never overwrite or modify files! Always create new!
After all, we all have got 500Gb drives in our laptops - we have to put them to work.
Posted by Dima Malenko 5:44 PM
Labels: Configuration Management
0 comments:
Subscribe to: Post Comments (Atom)
