 Reforming Project Management |
||
|
|
||
|
Friday, May 09, 2003
99 (Purple) Cows
Here's a treat for the weekend. Seth Godin published his book Purple Cows yesterday. It's a book about setting yourself apart. Seth says "Be reamarkable!" To coincide with the publishing of the book he wrote an ebook of purple cow examples -- remakable people and companies. You can get it here for free, or from Amazon for 10 bucks. You choose. You might be wondering why I can give it away for free? It was Seth's way of saying thank you for a nomination I made for the ebook. Although he didn't publish my nomination, he did send me the ebook and his encouragement for me to share it. Nice!
Get a dose of remakability -- 99 Cows. Thursday, May 08, 2003
Project Success Takes On-going Leadership
The Top Ten Reasons Projects Fail (Part 4) by Frank Winters, appearing on April 16th in Gantthead. This article is not about the 4th reason for failure. It's a continuation of a series. Winters has published five articles in the series. The series is good. This article is very good. In it Winters explores the role of leadership to project success.
When there is a leadership vacuum and negative inputs are coming from those who should be leaders, it's up to the PM to fill the vacuum and overcome the negativity. That's one reason the No. 1 cause of project failure--inadequately trained and/or inexperienced project managers--has everything to do with the project manager. The buck must stop someplace, and for projects that place is the PM's desk.Get this, Winters is saying project leaders must be in on-going conversations of why the project matters: The project manager's role includes an obligation to fully understand the goals and objectives and then do what it takes to lead the team in that direction. This almost always requires a constant stream of reminders of what the goals and objectives are. Very often, the stream goes up the chain as well as down. It's very easy for the team--including upper management--to forget why the project was commissioned in the first place. The project manager must not let this happen.Winters offers five characteristics of project managers:
PMs who are not true leaders leave the success of their projects to others--and to chance.It's the project leadership age. Wednesday, May 07, 2003
Project e-Tip of the Week
I received a number of comments and emails in response to last week's Project e-Tip. One theme came through: Use measurements for the purpose of improvement. Of course, that's lean principle #5 pursue perfection. So, this week I'm offering one of the first steps in pursuing perfection on projects: collect useful data and find ways to make sense of it. For that I recommend combining a five why analysis with Pareto charting.
Here's my second Project e-Tip:
Calling for Project e-Tips. Tuesday, May 06, 2003
Better Makes Us Best
I do too much writing about uncertainty, lean practices and methods, and the linguistic action perspective and not enough writing about what we find is the most difficult aspect of lean. It is Womack's and Jones' fifth lean principle: pursuing perfection.
Invariably I visit companies who have adopted a lean approach to project delivery, but they haven't adopted any formal practices of continuous improvement. Seth Godin writes Slowly I Turned...Step by Step...Inch by Inch... about the difficulty as being endemic to American business and our culture in general: We need to stop shopping for lightning bolts. The way out of our paralysis is simpler than that: It's about thinking small and thinking gradual.We are programmed to look for the quick fix, the overnight diet, the winning strategy. Womack and Jones will tell you while flow and pull are the distinguishing characteristics of the production activity, pursuing perfection is the general orientation that separates the Toyotas of the world from everyone else. Seth puts it this way: If every element of an organization gets a little better every day, then that organization will become unstoppable. An organization that builds that kind of momentum will soon evolve into a market leader.Jim Collins confirms that in his study reported in Good to Great. He says that breakthroughs come from consistently building up effort over long periods of time. None of these authors are saying something new. Who knows, we might even find a Ben Franklin quote on the subject. What these authors fail to help with is how to create a habit of pursuing perfection. Seth tells us: The truth is, gradual change is challenging and hard: challenging, because the people around you are demanding something great right now, and hard, because gradual requires the faith to know that your hard work is worth the investment.So how can we pull this off? The best advice I've read was from Dr. John Psarouthakis. Dr. John, as his employees called him, is a Greek immigrant who got an MIT education and later a PhD. After a successful career he went on to found a series of companies that became JP Enterprises. Those companies provide parts to the automotive industry. Dr. John wrote the book Better Makes Us Best. (It is now out of print, but can be found on Half.com and Amazon used books.) He describes an approach that I'll characterize as intense engagement. Dr. John encourages all staff to align their actions everyday with the mission of the company making it their personal goal to do better today than they did yesterday. He goes on to describe how management must shift their behavior and the formal systems to support the goal. We can thank Seth Godin for being the most recent person to call attention to the pursuit of perfection as the source for long term competitiveness. Now, let's take that advice and build practices for continuous improvement in our project settings. Monday, May 05, 2003
Taking a Lean Approach is Hard Work
Seth Godin writes A Brief History of Hard Work, Adjusted for Risk in Fast Company. Check out Seth's Blog for more of his views.
Seth contrasts the physically hard work with the emotionally hard work. He calls on us to face the fears of speaking up in organizations. The everyday hard work is speaking our opinions for the good of the project and the organization while doing so skillfully. I will continue to write about the linguistic action perspective (LAP) of project management. One significant impediment to adopting the LAP approach is dealing with the misplaced fear of being out-of-control. (Isn't control just an illusion?) As Seth goes on to say, Hard work is about risk. It begins when you deal with the things that you'd rather not deal with: fear of failure, fear of standing out, fear of rejection. Hard work is about training yourself to leap over this barrier, tunnel under that barrier, drive through the other barrier. And, after you've done that, to do it again the next day.Succeeding on projects is all about taking risk. The risk of sharing one's views and exploring others' views -- all for the sake of pleasing the customer. Remarkable! Sunday, May 04, 2003
Project Collaboration Requires Intent and a Shared Language
Johanna Rothman writes about Software Product Development. In a recent posting Language (and Language Environment) Influences Process Johanna writes about the suitability of (software) language for collaborative bottoms-up development. Change a word or two, here and there, and she could have been writing about architecture. At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some forms of pair programming. Why? Because the language, LISP, encourages this. It's easy to make small changes. It's easy to take what you have and try something. It's easy to walk someone through small functions and then have that person explain what else you could do. It's easy to grab someone and show them what you have already working, even if other parts don't work yet.So what does this have to do with architecture? or any engineer-to-order project? Maybe nothing, or everything. Johanna writes about using a programming language that makes it easy to collaborate and to work from the bottom-up. (Is there any other way to deliver projects?) Not only is LISP suitable to this style of development, I'd dare say the language anticipates a bottoms-up collaborative approach. Not all software development is collaborative and bottoms-up, just like not all architecture and engineering is collaborative and bottoms-up. The language helps. A pattern language for architecture and engineering would help collaboration. However, what's more important is an intent to collaborate and design or engineer from the bottom-up. The linguistic action perspective to managing projects is a general approach for collaborative bottoms-up planning, and therefore so is the Last Planner System™. There is an intention to let the project evolve as project team members learn with each other while delivering on the promises to the customer. Supporting that intention is a set of practices, like Johanna's description of LISP, that make it easier to start and continue to collaborate and work from the bottom-up. If you are not sure about the reasonableness of working in this manner, then think back to the last project that for whatever reason ran off the track. What did you do to right that train? If you are like most, then you got the folks together who were executing the project and asked them what they would do. Why not start out this way? Choose an approach (or language) that supports an emergent approach to project delivery. Visit the Archives for more postings |
 Reference Papers
|
|||||
| ||||||
