|
Journal Archives from New England Project Services To receive updates about the journal via email:
Journal items 36 through 27
Total number of journal items published = 36
|
|
Journal item #36, journal ID #76, published on 2/24/2005 at 1:41:21 PM by Mike Cooper
Benefits of Project Portfolio Management My colleague Frank Winters has written the first of a series of articles on project portfolio management for Gantthead, the first of which is Project Portfolio Management: A Primer (Part 1). He has initiated a discussion thread at Gantthead, where he posed the question "In your experience, what are the benefits of Project Portfolio Management (PPM)?". You might find both the article and the postings on the discussion thread interesting. Here was my posting to Frank's question: In a word, a key benefit I've come across when either helping organizations create a portfolio or doing so myself, is COMMUNICATION. This starts with visibility. There are many times when I've gone into a situation and had great difficulty understanding what people are working on, or perhaps better put, what are the major objectives of all the activities? Setting up a portfolio by just simply listing all the projects being worked on can be very illuminating. After you have achieved initial visibility comes the real value - using the portfolio approach to communicate with senior staff what is going on - the high level status of all the projects, what new projects are in the pipeline for consideration, what projects have been completed, etc. If you get around to it, you should keep projects in the portfolio long after they have been completed to track the actual ROI achieved. Now that this has been setup, and you can use it for regular communication, you can get smarter working with the business in terms of deciding whether an idea for a project should be turned into an actual project. In other words, working together as a team (IT and business) to manage the capacity of the IT organization. How can sensible decisions be made about whether to do a particular piece of work if it's not clear how utilized IT is and how far the current work extends into the future? Nobody should be daunted into thinking that there is something complex about setting up and managing a portfolio. It's a bit like project management - fairly simple to understand the basics, but tough to actually do well. Just starting with a simple list of all the projects, getting that agreed with the business and executives, can put you ahead of many organizations. Finally, not all projects have financial ROI. I'm sure Frank will address this during this series. Examples would be projects done to fulfill regulatory requirements. The financial cost of doing the work is important to understand, as is its consumption of resources, but the actual ROI may be more along the lines of "if we don't do it the CFO goes to jail". Now that's a project that probably will have no trouble getting funded! |
|
Journal item #35, journal ID #75, published on 11/28/2004 at 5:03:23 PM by Mike Cooper
One of my favorite questions to project managers. Q. What is the most important change on your project? A. The first one. Think about it. Mike |
|
Journal item #34, journal ID #51, published on 11/13/2004 at 10:55:39 AM by Mike Cooper
Sometimes it's the simple things Occasionally an article will stike me for it's elegance in presenting what appears to be the obvious, yet is often forgotten. The latest to fall into that category for me is 'Hi, I'm From IT, and I'm Here to Help' , an opinion piece from ComputerWorld on Nov 1. (To find it try this direct link, if that fails, go to www.computerworld.com and use the quick link number 49717.) Michael Hugos talks about how his company's IT department goes out to the business and looks for repetitive tasks that can benefit from automation. They rarely build large scale complex systems, instead focusing on helping the business do what they do faster. OK, you may think this means that they lose sight of revolutionary changes that technology can bring to business operations, but what it means is that most of the time they are providing real benefit via small scale projects that are an order of magnitidue easier to control than large ones. Here's an interesting quote from the article: "And since workflows change quickly and the most complex workflows change the fastest, why spend a lot of time automating them? Instead, learn to see complexity as combinations of simple repetitive tasks and automate the simplest and most repetitive of them." What's your take on this? I would not take this view to the extreme, but go read the article, it may remind you where the real focus should be; it's not about building complex IT systems, it's about helping the business get it's work done. |
|
Journal item #33, journal ID #45, published on 10/22/2004 at 9:10:36 PM by Mike Cooper
Same Old Problems? My colleague Frank Winters has written an excellent article on Projects@Work called "The Problem With Projects". Find it here. This article presents an overview of initial findings from a one-year survey of practicing project managers and team members at Fortune 500 organizations. PCI Global, an international project management training and consulting company, conducted the survey. The report identifies issues such as confusion over who is in charge, lack of project sponsorship, challenges with resourcing projects, and many others. The main thing that struck me was that this report could probably have been written as is 5, 10, 15 years ago. Sadly I expect it will be just as relevant 5 years from now in many organizations. I think the real interesting thing is not the findings of this survey - they show what many of us know - that the problems are simple to explain, and have been around for a long time. The real interesting thing is "why don't things change?". It has to be something to do with human nature. Perhaps something to do with lack of accountability? I think a study about this would be much more interesting. Key finding #4 is project manager scapegoats. Combine this with your (and my) view Frank that the #1 cause of project failure (read Frank's failure series) is the project manager with insufficient experience and / or training, and what do you get? Perhaps the root cause being poor recruiting / selection / training of project managers, so are the line managers really the main cause of project failures, by not putting appropriate project managers in place? I can see that even with myself, I have at times fallen into a trap of ineffective project management, if I work with an organization where the culture is not project oriented, and I am not being "managed" - although I I'm sure held accountable if things go badly wrong! There's lots of good things I do, but iI can fall into a trap of plateauing out instead of continuing to push for more improvements. It can be a lonely situation if you have precious few people in an organization who can effectively plan and track work other than yourself. I think that this kind of situation might provide input to a "why is it so hard to change things" study. Here's hoping you can continue to find areas for improvements, and actually get something done about them! Mike |
|
Journal item #32, journal ID #44, published on 8/15/2004 at 5:49:36 PM by Mike Cooper
The Project Manager and Their Interaction with the Finance Organization In my previous journal entry I mentioned that a third article in the "PM and their interaction with other critical organizational functions" was hopefully going to be published. Well, what happened was that Projects At Work decided rather than publishing the whole article to excerpt some views I put forward about project managers needing to think beyond "their" end of project and to their customers' end of project. You can read their comments with my views at http://www.projectsatwork.com/article.cfm?ID=218720. Because of this I have decided to publish the full article on our website, rather than find someone else to publish it first. So for a world exlusive first view of this article, you can find it here. You do need to be a registered member to access the article. Comments welcome either in the comment field to this entry. |
|
Journal item #31, journal ID #43, published on 6/20/2004 at 6:58:28 PM by Mike Cooper
The Project Manager and Their Interaction with Other Critical Organization Functions I've just published on our website an article that introduces a series about the interactions between the project manager and various other key functions in the organization, such as finance, sales, product management, legal, human resources, etc. I'd really like to hear your own stories of how either a critical support function behaved in a manner that was not in any way deemed supportive of your project, or went the extra mile and significantly helped your project succeed. I’d like us to share these stories and perhaps in doing so, enable us all in some small way to help bring our organizations closer together to make it more likely that our projects will succeed. Send me an email if you want to comment - I may use your input to the next article (after checking with you, of course). The following two articles on our website are part of this series, and a third article is hopefully about to be published. Selling Services - Coordinating Sales and Project Management Conflicting priorities between product and project management in a combined product / services organization I look forward to hearing from you! Mike Cooper |
|
Journal item #30, journal ID #42, published on 5/16/2004 at 9:53:26 AM by Mike Cooper
An Update To Our Non-US Members Back in February in this journal entry I wrote about an open letter from Russ Archibald to the Chair of the Board of Directors of the Project Management Institute (PMI) that addressed “eight critical issues that must be addressed in 2004 if PMI is to achieve its often stated goal of being a global organization representing the project management profession throughout the world”. To give you an update on what has happened, in the March edition of PMI Today, Greg Balestrero, the PMI Chief Executive Officer wrote a detailed 4 ½ page article titled “Progress Report on Serving PMI Members Worldwide”. In this report he included both Russ’s letter, and a point-by-point commentary on the issues. PMI Today is only issued to PMI members, and if you are a PMI member who has not yet read this (maybe you threw away your copy of PMI Today!) you can read it electronically by signing in to the members only area of the PMI website. Greg’s article talked about various strategies and the status of their implementation – far too much for me to report on in this one entry. With regard to Russ’s 8 points, he introduced his commentary by saying “Many of these issues have been resolved, while others have not”. The first point was about equalization of costs – the linking of the costs of PMI membership dues and PMP certification with the salary scales and exchange rates in each country. I believe this point is particularly important. What may be affordable to someone in the US may be unaffordable in many other countries. Greg says that this issue has been discussed several times within PMI, but not resolved. Part of the resolution is increasing the value in other countries, and progress has and continues to be made on local language translations of key PMI publications. This also addresses one of the other points, which refers to people receiving information in English even if it is not their language. Many of the other points deal with legal and administrative challenges of organizing and running PMI Chapters in countries other than the US. The other issue I particularly raised in my previous journal entry was selling the product of PMI volunteer efforts. I stated that “I firmly believe that PMI should more freely disseminate project management works to further encourage adoption and use. I recognize that there are copyright constraints, but this is not an obstacle - the mindset of charging for everything is the obstacle.” With regard to this, the commentary was basically that other similar organizations charge for these offerings, that PMI invests considerable money in developing these offerings (nearly $1M to develop OPM3) and that many other organizations charge members for individual standards whereas PMI provides them free to members, and one of the standards is available in many languages at no extra cost to members. I understand all these points, but I don’t accept it. The only thing I accept is that PMI cannot lose money as an organization. Just because other organizations charge for offerings is no reason why PMI should – PMI could take a stance that it will try and provide as much as possible free of charge to members (and non-members) to promote the practice of good project management. I’d rather see more materials made available at no or lower cost, than a fancy multimedia presentation at the annual North America Symposium, for instance. If you have any particular point of view about this topic, just add a comment below. Bye for now, Mike |
|
Journal item #29, journal ID #41, published on 3/5/2004 at 1:39:14 PM by Mike Cooper
About Estimating Projects with a High Degree of Change Regarding one of Frank's recent article on reasons projects fail which discusses poor effort estimating (see here for the article), people sometimes struggle to even attempt to give an estimate for a project where it is anticipated that there will be a high degree of change. It can often help to consider the triple constraint triangle - you know, the triangle with the three sides of cost, scope, time. Change one and at least one of the other sides changes. Well, when considering a project where scope cannot be clearly defined early on (perhaps a new type of application is being built in an iterative manner), the scope side of the triangle is subject to change. Perhaps we can constrain one of the other sides. Consider time. Perhaps we can define a project life cycle whereby we will do the following: Step 1 - develop high level project scope, identifying the main objectives Step 2 - develop an overall technical architecture Step 3- develop a release, consisting of the following substeps: Step 3A - spend one week developing a prioritized list of requirements with the users Step 3B - spend two weeks developing the release. Stop work after two weeks. You may not have implemented all the requirements, but you knew what priority order to implement them in Step 3C - spend one week stabilizing the release, testing it. Step 3D - spend one week training users and deploying the release. Now go back to Step 3A. In effect, decide how many times to go over the Step 3 loop. We can now predict how long this project will be. If we do three iterations, our project will be 15 weeks plus whatever Steps 1 and 2 take. So we are in a reasonable position to make an estimate - if we can constrain the resources on the project, say we provide one full time business analyst, two developers, one tester / documentor, and a parttime project manager, we can now easily create a reliable estimate. Of course, we still don't know exactly what we are producing, and we may find out that we need a fourth, or even a fifth, iteration. But these can be handled via our change control process (you do have one, don't you?!?). After each iteration you should re-examine the business case for proceeding. Of course the above is only an example, you may need longer, or shorter, loops. But this approach can be used to obtain a budget and a timeline for what at first might seem to be an impossible to estimate project. Mike |
|
Journal item #28, journal ID #40, published on 2/27/2004 at 12:28:28 PM by Frank Winters
Here are some thoughts on managers – project managers and others – and the characteristics of those that deserve our respect and support. "Don't confuse me with facts." That was one of the first things I learned about how business managers think. This was back in 1963 and I was a new computer operations guy. The VP of Ops at the Fortune 50 I had just joined said he preferred to remain fact free as he thought through a particular problem. He was kidding, he said. But in my experience, many managers act as if they really, truly don’t want to be overly burdened with facts. Thing is this hasn't changed. Near as I can tell many managers don't want to take the time to learn what might help them solve their problems or set direction -- they just want the problems solved, and get on with it -- damn it! I guess this is "human nature". We humans are generally don’t like to take the time to figure things out. We don’t like to spend time dealing with facts and we don’t like to take the time to gain and understand advice. We like to just do it! (Beware of slogans from sneaker or beer companies.) I think this explains why project managers very often don’t do what they know they should do – it seems time consuming – just when we are most busy and under pressure, how can we stop to take facts or advice on board? After all, facts need to be understood and getting advice means we need to explain our situation to the advice giver, allow enough time for the advice to be created, get the advice – then we need to understand it! That’s too much like work and way too time consuming! It’s much better to just solder on and hope that it all comes out right. A critical factor of good business management is the use of consultation prior to decision making. The manager has the responsibility to make decisions but should always consider both the facts and the advice of those she trusts. A critical success factor for managers at every level is the identification of the trusted lieutenants, confidants and consultants that can be counted on to give good advice. Beware of managers that surround themselves with people who seem to be just like the manager and/or are merely “yes” people. Beware of managers who seem incapable of consulting with others. Beware of managers who manage by simply demanding results. If you find a manager to work for who seems to be capable of integrating the best thinking of the people he or she trusts, you have found someone worthy of your efforts and allegiance. Treat such a manager with great respect and give your support to a member of a rare breed indeed! |
|
Journal item #27, journal ID #39, published on 2/14/2004 at 9:43:19 AM by Mike Cooper
What's Your Experience of Using PMI Materials? I was reviewing a publication from the Project Management Institute this morning called "Project Management Experience and Knowledge Self-Assessment Manual". It's a great concept that is reasonably well executed, although I suspect many organizations would want to modify it to fit their particular needs (this is not the intent of PMI which would regard this, rightly so, as assessment of generic project management skills). This lead me to writing an email to PMI about two topics: 1 The use of this book to question how and if organizations can modify the question set and how PMI can make it more user friendly by providing a spreadsheet rather than just the paper book. 2. To consider how to encourage a discussion amongst people, hosted by PMI, about their actual experieces using various PMI publications, such as this, PMBOK, OPM3 (this has its own discussion forum), WBS Practice Standard, and others. I'd be interested in hearing from people about their practical experiences of using PMI materials in their organizations. For instance, I have worked with an organization to help them develop an approach to project management, and they used the PMBOK planning section to help develop the Project Plan for this improvement initiative. It worked well. What about the rest of you? I'll let you know if I get any significant feedback from PMI on the email I sent them. Till later, Mike |