project+management category archives

I breezed through Jim Benson's short and informative Why Plans Fail: Cognitive Bias, Decision Making, and Your Business. As you can see from the subtitle, it isn't about blaming someone else for why plans fail. It's about helping us see how our own thinking gets us in this mess.
A local paper has a great quote that is takes four times longer to complete two tasks effectively than to do each one individually.
Great find by Michael Krigsman on project management lessons in an academic paper. Nice reminder that idleness is only a problem when it is attached to value in the organization: idle projects / products.
Don't use milestones to manage your projects. Use buffers at key integration points and a project buffer at the end. This is a much more reasonable way to manage your project and the natural variability of execution.
Yesterday doesn't mean much when I want to know the status of the project and whether there are any bumps on the path to getting to done.
Pay attention to what you are doing. Think beforehand, and then take action. And of course, check that your actions are taking you in the right direction and correct course as needed.
Recent research suggests that (IT) projects are ticking time bombs, but does it have to be this way? CCPM can help.
Interesting commentary from Bruce Benson on protecting imperfect data and plans. He suggests and I agree that we should give as much as possible to people, so they can take action.
Overview of Larry Leach's "Lead Project Leadership" in which he blends CCPM with other improvement perspectives and straight up Project Management skills.
Andreas Scherer's business novel, Be Fast or Be Gone, was a very fast read for me. I thought it did a great job of describing how Critical Chain Project Management might be introduced to an organization without going into the gory detail of what-is-CCPM.
Geoffrey Moore talks about reaching your escape velocity in a Stanford Entrepreneurial Thought Leaders podcast. I took away another version of the dangers of multitasking - at the team level.
Fun with workload limits from Scott Adams and Dilbert.
I've been added to a list of "best project management blogs." Nice.
Some thoughts about recent discussions of Agile and Kanban on the Critical Chain mailing list. There are a lot of useful places where they work together.
Wrestling projects is no fun. Instead of patching more and more policies on top of the project environment, deal with the source of the problems: variability and communication.
Wired did an interview with Fred Brooks in connection with his book on design. He's got a familiar comment about your constraint - it isn't always what you think.
I just finished David Anderson's _Kanban_, and I really enjoyed it for its sensible combination of ideas into something that really seems to work. And while he doesn't discuss it, I see application in many other areas than software development.
Whenever a change is introduced, the people who have created the change are the most familiar with the new situation they want to create and why it should be created. But everyone else? They either have limited or no knowledge of why things should change and how this specific change will meet their needs.
When can waiting get you to the finish faster? When you wait until everything is ready, and then move quickly. Thanks to Rudi Burkhard and Boaz Ronen for inspiring these thoughts.
Derek Huether has an interesting thought about Measuring (Project) Health. There are many ways to go about doing this, some useful and some not-so-useful (and some downright destructive). Derek's example this time is more of a check-up on the status of your project work.
Josh Nankivel, the PM Student, posted a video about a month ago that I finally got around to viewing. It is How Kanban Helps Prevent Multitasking on Project Teams, and he describes exactly that.
Michael Krigsman of the IT Project Failures Blog backs up and gives us Three simple truths of failure - based on a Dilbert from last week. Interesting comments.
Joe Dager's Business901 podcast this week has an interesting interview on Creating Flow with Don Reinertsen. While I enjoyed the entire podcast, the thing that piqued my interest in particular was around using these ideas in managing flow. Real execution advice.
It's Student's Syndrome: waiting until the last minute to do anything, usually because they have plenty of time - and because there are many other things to do instead. Only it is worse than I had previously thought.
It is so important to tie changes to outcomes and set expectations for new behaviors and new actions for people. It is difficult to change ingrained behaviors if people don't know what else to do.
A review of the TOC Handbook chapters on project management. It's good stuff but very dense. This is close reading and re-reading material, not something to read when you are tired.
In the latest McKinsey Quarterly, Eric Matson and Laurence Prusak have a brief article on Boosting the productivity of knowledge workers. They highlight five key barriers that come out of their research on knowledge workers and their interactions: physical, temporal, social / cultural, contextual, and temporal.
Realization's Project Flow 2010 conference was loaded with customer case studies and interesting discussions in the hallways. I thought there were some interesting themes and ideas across all of the presentations.
Realization repeats their mantra throughout the conference and in many of the customer presentations. The mantra elements: 1) Pipelining. 2) Buffering. 3) Buffer management.
How are projects measured today? How should they be measured?
My friend (and neighbor) Johanna Rothman has a piece in her newsletter which she calls, Park Projects You Can't Staff, For Now. It's a very good way of describing the common problem businesses put themselves into: too much work in process.
A few years ago (when I was a teenager), I recall a friend's mother telling me something along the lines of "Ignoring someone is the height of ignorance." The implication being that it is offensive to the person you aren't paying attending to.
I came across "Retrieving Projects from Bad Performance" on LinkedIn, in the status update of the author, Shridhar Lolla. Brief and interesting discussion with a TOC flair.
How many systems are out there for tracking the status of a project and the tasks within that project? Whose responsibility is it to gather and compile these status reports? Is it the manager, project manager, some software? Is "get the status" the wrong things to consider? The Manager Tools podcast on "Assign Work AND Reporting" gives me a new view of this question.
There is more discussion bouncing around the idea of knoweldedge work and visibility. The group has decided this is called "observable work." I've used "explicit" in my title simply to reference the long-running discussion of explicit-implicit-tacit in the knowledge management world.
If you don't learn from your mistakes, you are doomed to repeat them. If you don't learn from your successes, you can hardly improve upon them.
An interesting find of the "Nine Project Management Fallacies" by Rick Brenner of Chaco Canyon Consulting. These are not fallacies about building projects or executing projects, they are fallacies around how we think about projects.
It's so easy to get caught up in measuring things and forget why you are measuring.
Jim Hassett of the Legal Business Development blog has a great set of posts on project management: What every lawyer needs to know about project management. He does a good job of addressing a lot of the topics and questions people might have as they start thinking about moving to a project management model.
I have said this before: many organizations have far more good ideas than they have the resources to execute those ideas. I was listening to a recent Harvard Business IdeaCast and my ears perked up when they started talking about multitasking.
Pointers to a couple case studies on process improvement from MIT and focusing on a division of Ford Motor Complany.
I've been enjoying Glen Alleman's rants about the proponents of "project management 2.0." This time he makes some interesting observations about the role of people talking to each other vs. doing status updates.
Visible buffers give management a way to manage the system. And they also give the project participants a way to guage
In the middle of the behind the scenes video on how they built the Rube Goldberg machine for the OK Go video, Adam Sadowsky repeats the words in the title of this piece.
Glen Alleman has some interesting thoughts about uncertainty in projects and whether we need to estimate better. I wonder if theory of constraints and buffer management points to a different solution.
Henrik MÃ¥rtensson has a nice discussion of how an extreme focus on "cost effectiveness" can severely damage an organization with this mindset.
Several conversations have me thinking about why projects - any kind of project - falls off the rails so many times, even though people have articulated the lists of why this happens over and over again.
How Smart Leaders Talk About Time is a "Conversation Starter" from HarvardBusiness.org in October. It talks about the the struggle so many businesses have of having too many things to do and prioritizing amongst them. What is a leader to do?
How in the world do you get MS Project to show you the calendar-day duration of a task when the "working calendar" of the project is a 5-day work week (or a two-shift, 5-day week; or a three-shift, 7-day week)?
There are always more good ideas than we have resources to execute those ideas. Dennis Stevens has a look at this from the Agile perspective that inspires my thoughts here.

Note: Only the most recent 50 articles are listed. For more in this category, please search or look through the date archives.

Picture a steaming coffee cup. Better yet, grab one and have a read!

KJolt Memberships

Follow jackvinson on Twitter

View Jack Vinson's profile on LinkedIn

Blogarama - The Blog Directory