project+management category archives
Ihab Sarieddine has a nice overview of CCPM in his blog on project management, "Improving Scheduling Using Critical Chain Project Management (CCPM)."
I've had the Stop Starting, Start Finishing brochure / comic from Arne Rock and his team sitting in my briefcase ever since the Lean Kanban conference last spring. It's a fun read about how Justin (Time) does a Kanban implementation.
Working with clients on project management, as I do, I see a familiar theme come up over and over again. People have a difficult time separating the creation of an idea from starting to work on that idea.
Project management and knowledge management are about getting things done. I attended and spoke at the Center for Business Information (CBI) 6th Annual Forum on Knowledge Management this week in Philadelphia. Rather than talk about knowledge management directly, I opted to speak about managing projects - whether they are KM or other types.
Philip Marris, who I met at this year's TOC ICO conference in Chicago has published a nice case study of Critical Chain, focused on problems common to the pharmaceutical industry.
It seems obvious to say some of these things, but not everyone knows how to use email better. Here are some basic hints.
Portia Tung has a choose-your-own adventure version of a business novel, this time about going into a client as an Agile Coach (consultant) with five days to turn things around.
The Boston Globe had an article on "How to make time expand" this weekend. Interesting research suggests that giving away time creates the perception of having more time.
I attended an interesting talk by Dan Vacanti last week at the monthly Agile New England meeting. I enjoyed the talk overall, and I particularly enjoyed his emphasis on the Cumulative Flow Diagram as a key diagnostic tool - it's predictive.
The second half of the day today was devoted to breakout sessions on each of the TOC application areas. The stated goal was on having people familiar with these applications discuss opportunities for improvement. I decided to sit in on the projects (CCPM) discussion.
Thought without action is a dream. Action without thought is a disaster.
Tuesday opened with a fun, story-filled keynote from Gregory Howell of the Lean Construction Institute. He had some interesting things to say about commitment and collaboration in the context of projects.
Tony Schwartz has a great piece on "The Magic of Doing One Thing at a Time" that has inspired a lot of comments and additional conversation. Multitasking - and eliminating it - is an important topic to doing well as an individual as well as in organizations that want to get stuff done.
There is a new research survey out there on Critical Chain Project Management implementations. If you have ever participated in or run a CCPM implementation, please go take the survey.
How often do initiatives get bogged down with the introduction of shiny, new tools instead of the meat of the change?
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.
Note: Only the most recent 50 articles are listed. For more in this category, please search or look through the date archives.