Glen Alleman asks “Why is it so hard?” and focuses on one of the most difficult line items for IT projects to fund: project/program management, including contract planning and controls. 

I’ve had varying success in positioning these resources, so I’m still stumped.  Arguments that worked for one initiative failed for what should have been a similar initiative. 

So here are two questions to you all:

1. What arguments, research, findings, etc. have been EFFECTIVE in ensuring that your projects or programs have the leadership they need? 
2. Does these “effective” factors work better for one type of project over another?  In other words, do some types of projects lend themselves to “selling” project management better than others?

Filed under: PMO Tagged: benchmarks, estimation, Program Management, Project Management

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

Ten Ways to Ensure Project Failure By Ahmed Hafeez Sometime ago I read an article about the top ten ways to destroy the earth. Although it is a bit morbid to even think about such a topic let alone compile a top ten list, it certainly is an interesting scientific problem. Blowing planet earth to bits is [...]

Geoff Crane of Paper Cut Project Monitoring described his TwitterView with Jhaymee Wilson. I had not heard of a "TwitterView" before this. It seems to be an interview over Twitter.

I've been interviewed twice this year (2010), once by PMI for an upcoming article and other time for a commercial Blog. Both times were around an hour on the phone and an editorial session after to do the "fact check" and final edits of the interviews.

What came to mind with Geoff's post  is doing an interview with two tuna fish cans and a string.

We did this as kids. It's half duplex, low fidelity, highly distorted. Fun but not very effective.

Endless studies have shown that communication between people is largely through body language and expressions. Then comes tonality, and finally the words themselves.

Now I enjoy Geoff's Blog very much and the people he points us too as well.

But I still have gotten my mind around the notion of Twitter as a communication channel for anything other than exchanging short - almost context free - messages. 

I live on IM with our field staff. It's a way to see who's in, a quick check up on something that can be resolved in a very few sentences - like ONE. For example - "who's using the WebEx account?" "Hey Matt, I'm headed to 59th facility, you gonna be there for lunch?" "Hannah, you coming to Breck this weekend with your roommates?" "Honey, stop by Safeway and get two bunches of green onions." Stuff like that.

Serious adult communication seems to require a wide channel.

Managing projects requires an even wide channel. No waving, no doodling on the reports, no looking at multiple pieces of paper at the same time, no sensing of the facial expressions to see if we're actually exchanging information rather than just textual characters.

Someone please tell me what am I missing here, where the PM2.0 advocates claim this is the "next big thing," in the domain of Project Management?

Changing Taiwan's Project Management Outlook Roger Chou, PgMP

These points lifted from an article by Gary Hamel from late last year;

• In every industry, there are huge swathes of critical knowledge that have been commoditized—and what hasn’t yet been commoditized soon will be.
• Given that, we have to wave goodbye to the “knowledge economy” and say hello to the “creative economy.”
• What matters today is how fast a company can generate new insights and build new knowledge—of the sort that enhances customer value.
• To escape the curse of commoditization, a company has to be a game-changer, and that requires employees who are proactive, inventive and zealous.

Given this argument, what are we doing to make our work more creative?

Control Factors in Project Management - Money (#2 in the series Coordination of Projects in Project Management) By Wouter Baars The evaluation of financial matters by a programme manager involves the following issues: Is the project as a whole, and the following phase in particular, adequately financed? What are the possible financial risks of the project? Should a go/no-go [...]

Apparently, John Quincy Adams, the sixth president of the United States said that. I like that quote because, while so much writing, research, and advice focuses on what leaders say and do (which is right), sometimes people forget that the measure of a leader is found in how he or she affects others, and Adams makes the point so well.

I encountered this quote in an "inspirational" slide deck with music called "Are You A Leader," which was apparently done by a company called Signature. A reader named Matt was kind enough to point me to it, suggesting I might like it.  I did like a lot of the quotes in it and it was well done, although it is a little too pretty and uncritical for my tastes, but that probably says more about my personality than the quality of the deck -- which was clearly done with much thought and care.

Yesterday I had a bit of an argument on Twitter about differences between Scrum and Kanban. Personally I don't care which is better than the other, because I believe that all models are wrong, but some are useful. And both Scrum and Kanban can be useful, given a certain context.

In yesterday's keynote speech at the Scrum Gathering in Orlando Jeff Sutherland said he had seen teams that were "doing Scrum" while they didn't even have a backlog. And there are reports of "Scrum teams" not practicing daily standup meetings, and teams not delivering a new product release every week.

These are not Scrum teams. They are ScrumBut teams. They do Scrum, *but* without some of the key ingredients.

Unfortunately, some people arguing against Scrum include these ScrumBut teams in their evaluations of the "high failure rate" of Scrum. They love quoting that "at least 75 percent of Scrum implementations fail." And I think "Yes of course, 75% fails when that includes the teams that don't understand what they're doing."

I believe that right now Kanban doesn't suffer from this problem. Kanban doesn't have a high failure rate because Kanban is still at the start of its adoption curve. Only very smart people like David Anderson and Karl Scotland are practicing it. And they know how to do it right!

But just wait a few years and see. When idiots like me get their hands on Kanban, we will start implementing KanbanButs, but we'll be calling it Kanban. We will have absolutely no idea what we're doing, because value stream mapping is not as simple as story point estimation. And we will introduce "Kanban teams" without limited WIP, or "Kanban teams" without a vizualized workflow.

Then the world will see a 75% failure rate of "Kanban" implementations.

And then there will be a great new software development method called Bonkiborki (which is the Mongolean word for 42). And I will have invented it. And it will have a much higher success rate than Scrum and Kanban, because I will be the only one who knows how to do it right.

(image by Misserion)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Yes, Good Managers Are Manipulators
Reduce Your Fear, Increase Your Status
Planning for Feature-Complete Deadlines

We've added Zendesk to the list of applications that Tracker integrates with. Zendesk is a "beautifully simple", on demand customer support help desk system. This integration allows your development team to prioritize and collaborate around Zendesk tickets as linked Tracker stories, bringing development and support closer together in your organization.

To learn how to set up Zendesk integration for your project, visit the integrations help page. Once enabled, you'll see a new panel in your project, allowing you to see and drag/drop Zendek tickets into the backlog or icebox. Story comments and state changes will appear in the corresponding Zendesk ticket as comments.

Note: At the moment, the Pivotal Tracker target in Zendesk does not create linked stories in Tracker. We're working with Zendesk to enable that, and make the two integrations seamless.

One of my favorite things about the Internet is how so many random pieces of information can converge upon my life. My web browser is the window through which I view most information that comes my way. I'd like to share with you a couple of interesting people who have found their way into my news reader in the last year.

What's my mantra?
First up is Alan Cooper, whose company has a blog, but it was their book that was brought to my attention by an article in my news feed. Cooper wrote The Inmates are running the Asylum and one of his key points, nay his mantra, is to always remember that the end user is not like me. Each of us have a key set of assumptions and filters through which we view our world and those assumptions and filters are not likely to be the same set used by our stakeholders.

Think about it... if I said to you that I want a sandwich for lunch, what exactly would that mean? If we know each other well, you would likely guess the fast food joint and possibly even the meal I would purchase on any regular day. But what about on those 'non-regular' days when instead of a hot pizza sub, I want a club sandwich at a sit-down restaurant? Even my best friend would have a hard time guessing where and what I want to eat, given all the possible meanings to my stated desire of a 'sandwich'.

The same principle applies to business analysts and our customers. We all have been told at one time or another that our end users don't actually know what they want, but its the job of a BA to 'elicit' or 'draw out' their true needs. We spend our time trying to dig down to the root of a problem, then help the stakeholder either find a process change or the development team a system change to address the need. Sometimes our customers have easily defined problems ("When I click this button I get an error") but sometimes the issue is not so clearly defined ("I need to know more about my customers"). If the BA uses only their own filters to tackle the problem then the answer will be very unlikely to resolve the customer's actual problem.

It all comes down to finding the right perspective or lens through which we can view the problem. I remember my very first project as a BA, being brought in at the very end of the project to write process documentation and training material for the business unit in which I had spent the last three years as an employee. My first thoughts when seeing the new application almost ready for implementation were, "This system is so bad my friends are going to hate me when I demo it for them." Even though there were people who had spent years on that project, who had also previously spent years in the business units, they had used the mental filter of a pre-selected software package to view the problems found in the business area.

While many people recognized that the proposed application had issues, no one was willing to put a stop to the project even though it would have been detrimental to the business area to switch them to the new program. I breathed such a sigh of relief when the project was eventually canceled, knowing I would never have to stand in front of my colleagues and present a 'solution' that was a bigger mess than their problems. Had someone taken a look at the problems of the business area prior to selecting a vastly inferior software solution, the company might not have wasted so much time and effort on a project that was doomed to fail.

What is efficient?
My second insight comes from Jeff Atwood, who runs codinghorror.com, and is about the concept of system optimization. Being a programmer, Atwood has a passion for producing well-formed, elegant code. Being a programmer who understands and tries desperately to meet his customer's needs, he understands that having the most efficient and maintainable code does not equate to having the most effective product for his customer.

One of the things I appreciate most about Atwood is his ability to see more than just programming standards and guidelines, but to see how the use of those tools can improve the applications he creates for his customers to use.

One of the traps that I find good developers often fall into is not seeing the difference between well written code and code that meets the customer's needs. Having code that executes flawlessly, that crunches numbers in record time and does all this in a way which can be easily maintained by any novice developer is a good thing, but if the software does not help the end user reach their goals, the application is still a failure.

I remember one conversation with a developer who deviated from the design document to make what he thought was a trivial change, all in the name of system efficiency. It sounded good on paper as he'd save a few processing cycles and the end user would not notice any difference when using the application. The developer neglected to realize two very important facts about the repercussions of making that change. First, while his change improved the code efficiency, it did so needlessly.

We're talking microseconds saved on a transaction that already took less than a second to process.

This transaction only occurred a few times per month and was performed on a server whose average load was around 10% and whose maximum load was 50%. In other words, the developer spent more time redesigning something that would have worked just fine as designed than would ever be saved by making the change.

Even then, the change wouldn't have been a big deal, until you realize that if the functionality in question ever had a problem, the support team would now have considerable difficulty in trying to get the user up and running as quickly as possible.

The new implementation was technically correct, but prone to misdiagnosis by the helpdesk. Sure, training could possibly help, but remember how rare the transaction occurs and then remember the turnover rate for a support team and you'll realize that whenever this function does receive a call, no one who takes the call will likely have been trained on how to handle this one-off situation.

When the helpdesk tries to resolve the issue as they would any other similar problem, the steps they would take that would have fixed the problem under the original design now will not work. Not only did the developer not add value with their change, as there was no perceivable benefit to the user, they actually introduced additional support costs, all in the name of code efficiency.

Your Turn
So what is in your news feed? What articles have you run across in recent times that may not be directly related to your job, but that gave you thought on how you might improve as a BA?

The career path for a project manager is pretty straightforward.  Start on project support and small projects, manage bigger and bigger projects, then become a programme manager.  Some people would argue that programme management and project management are different skill sets and programme management is not necessarily the natural progression.  But programme managers earn more than project managers – and most people would see more money as a step up on the career ladder.

But going up isn’t your only choice when it comes to moving jobs.  Taking a sideways move can be very profitable as well.

“There are actually more reasons to take a lateral move than to accept a promotion!” says Martha Finney, co-author of Unlock the Hidden Job Market.  She lists the following as incentives to hop sideways:

• “You love the company but hate your boss.
• You love the company and want to build your portfolio of skills and experiences to make you more valuable on the corporate track – such as different corporate functions or global experience.
• You love the company but recognise that maybe the days are numbered in your particular business unit and you want to switch over to a more promising division.
• You love the company but see that the only available opportunity for you to stay there is a lateral move (your current job is being phased out, you want to live in a specific geographic location, etc).
• The lateral move is part of a formally established developmental program that you trust.”

A sideways project management move means picking up a similar role to that you have now in a different organisation or division of your current company.

Nancy Mellard, executive vice president and general counsel for CBIZ Benefits & Insurance, puts it like this:  “I define lateral career moves as when you can take on a new department, project, people or responsibilities. These moves should always be made,” she adds.

Diane Youden, a partner with PricewaterhouseCoopers specialising in HR effectiveness, agrees that moving sideways can be advantageous.  “Without a doubt, more senior roles require the ability to quickly assess a broad range of situations and their impact on the business strategy,” she explains.  “Experience is the most impactful ‘training’ you can receive to broaden your points of view and enable you to think more holistically and strategically.”

If you are going to take a new project management job that moves you sideways, you want to be sure that it really will help your career in the long term.  “Ensure that the lateral move is perceived as an enhancement to your career,” says Youden.  “As companies look for the talent of future, attributes such as adaptability and flexibility in dealing with change and new situations are key to being considered for more senior roles.”

Project managers adapt to new situations with every new project, so that type of challenge will be nothing new to you.  However, the difference between taking on a similar project in the same team and switching companies to do a similar role is huge.  Learning about a different company culture – not to mention their project management vocabulary and processes – will give you the variety and breadth of experience that looks great on a CV.

You don’t have to move companies to take a lateral move.  Mellard believes that if your company has a mentoring scheme you should take advantage of that to gain experience in other areas through lateral moves.  “Mentees should be challenged and encouraged by their mentors to find what lateral moves they can make in their current position,” she explains.  “Mentor programs should focus on the breadth of experience the mentees are obtaining and lateral career moves can provide this span of knowledge.”

Regardless of whether you are considering staying put or moving on, any new project management job offer needs to be carefully thought through.  “As with all aspects of your career, seriously consider all the opportunities that have been put before you,” says Finney.  “Don’t make emotional or hasty decisions.  Also factor in the question of where you are in your career. If you are just beginning your career, you can afford to take more, but calculated, risks – even if it means passing up on a small financial increase in your take-home pay. The experience is far more valuable than the cash.”

Related posts:

1. A question of shopping There were plenty of questions about project management at last week’s womenintechnology event on how to be a successful woman in IT. Mainly people were...
2. Taking the guess out of success Organisations don’t define failure. We don’t document how we will know if a project has failed – what failure looks like – because thinking about...

I opened that The New York Times Books section yesterday, and there it was: Chip and Dan Heath's new book Switch: How to Change Things When Change is Hard was Number 1 on the "Advice" list (a list that is usually harder to get on than thr Nonfiction list).  My reaction was "Holly Cow," or as as I wrote Chip, it was really "Holly Shit."   Number 1!  This is their second New York Times bestseller and second masterpiece in a row following the now classic Made to Stick.  I read a pre-publication version not because Chip and Dan sent it to me, but because my wife Marina Park -- CEO of the Northern California Girl Scouts -- got a copy (along with thousands of other people like her in positions to bring about change). This is not only a brilliant marketing strategy, it means that the ideas are spread and will be used by people in positions to do the most good.   As you can see from Marina's  blog post, she found the book to be extremely useful in thinking about both her role and other social problems.

A toast to the Heath Brothers, two guys who have woven together evidence-based ideas and great stories to write two of the most useful books of our era.  Indeed, many authors write about things they can do well themselves, but these guys not only write about ideas that spread and stick, and how to make change happen, they demonstrate their working knowledge of these topics by implementing  brilliant marketing strategies.  And on top of that, they are two of the nicest guys around.

Vendor Management - Project Managers Get a C-minus By Samuel Prasad Project managers are woefully ill-prepared in the area of procurement and/or vendor management. I am being very generous when I give them a grade of C-minus. Price doesn’t matter and SLA’s (service level agreements) are only marginally important. It sounds quite dubious, and I am sure I [...]

You have been a successful techie for several years. You have been working as a team leader at your current job for past eighteen months and you have just successfully completed a huge in-house software development project. Your project manager just got transferred to PMO with a promotion and you are the natural choice of your company to fill that vacant slot.  The company sends you for in-house project management training so that you understand the company’s processes and follow the guidelines of the PMO.  You are excited but bit nervous about your new role. You have acquired the theoretical knowledge about project management methodology and the company’s processes from the training you just completed but you do not know how to effectively implement them in your project.  At this stage anybody would be nervous as wise men said, “you do not know what you do not know”.

Relax! Here are the strategies to function effectively as a project manager and if you follow my simple albeit effective guidelines, you will be very successful in your new role as a project manager.

Step 1:  Understand top ten reasons of a project failure and proactively plan to avoid them.

Step 2:  A project manager spends over 80% of the time communicating. Have a solid communication plan not just a strategy.

Step 3:  Change is inevitable in a project. The problem is not the change itself but how you manage a change. Learn how to manage changes.

Let’s start with step one: Top ten reasons of a project failure.

1. Poor planning: Planning is the most important step of project management process. Half of the battle is won when you plan well. Coordinate with the project participants and the stakeholders to develop a detailed plan for the assigned project. Involve your project team members in planning and have the team buy-in. Prepare project scope, statements of work, work breakdown structures, task estimates, and specific tasks and milestones. Plan resources and schedule for your project implementation. Proactively plan effectively all anticipated bottlenecks, which include but not limited to management escalation, project prioritization, finding the right trade-offs between the business needs versus technical as well as triple constraints namely; scope, cost and schedule.

 2. Unclear goals and objectives: Many IT projects are elaborated progressively and in these scenarios you as a project manager need to rely on rolling wave planning. Initially the goal of your project may be only partially clear due to a poor requirement gathering in the definition stage of the project and you may not have clear picture of the scope and the schedule.  Defining clear requirements for a project can take time and lots of communication. You need to have expertise in rolling wave planning and that is where you should proactively focus.  You have strengths as well as weakness in this area. Being a technical team leader you can clearly view where the project is heading and you can very well anticipate the technical requirements and the future enhancements but at the same time you do not know how to plan for something that may be the future requirements. The best thing to do in such scenario is to rely on expert judgment.  Find project managers within your organization who have experience in rolling wave planning and seek their guidance. Your strategy should be to combine your technical expertise with experts’ judgments so that you can plan for your project that going to be progressively elaborated.

3. Poor Stakeholder Management: Identify stakeholders and bring them early. Project stakeholders’ interests may be positively or negatively impacted by the project and that is why stakeholders’ influence on the project is the most important thing to consider. Stakeholders who are found later will make changes and could cause delays. Any change that is made later is harder to integrate and is much more costly.

4. Scope creep and Feature creep due to objectives changing during the project: Scope creep refers to uncontrolled and unexpected changes in user expectations and requirements as a project progress, while feature creep refers to uncontrolled addition of features to a system with a wrong assumption that one small feature will add nothing to cost or schedule. Understand project trade-offs and make decisions regarding objectives on the basis of rational insight. Try to prevent project scope and feature creeps by implementing effective scope control methodology.

5. Unrealistic time or resource estimates: Many times project managers makes costly mistakes while estimating time or resources. Always work in a collaborative environment with the team and have the team buy-in and also consult with the project stakeholders as much as possible while preparing the detail project scope statement so that you do not make costly mistakes while preparing the WBS. Also employ effective techniques to estimate the amount of time each activity is expected to take. Be careful not to (common mistake new project managers make) use linear approximation when estimating the schedule For example, if you double the number of developers, you can cut the project time in half. In reality, doubling the number of developers produces a non-linear result.

6. Improper delegation of task and responsibilities: Many times project managers fail to delegate task and responsibilities to the team such a way that it should fit a team member’s job description. Organize the team such way that everybody should work under his/her own specialization so that the team as a cohesive whole performs the work diligently and within time and budget and thus raise efficiency above standard.

7. Lack of executive support and user involvement: Carefully listen to the executive management and the project sponsor and try to find out whether they have reservations about the project. If so, what is their vision for the project and what are their business objectives of the project. Try to work as an interface between the business and technology sides of the company so that you help our company align business with its projects.

8. Failure to communicate and act as a team: Projects sometimes fail due to improper communication.  A great deal of a project manger’s time is spent on communicating. We will discuss more about communication strategy in step-2.

9. Lack of proper risk management: Another potential cause for project failure is the IT managers’ inability to categorize all the risks qualitatively and quantitatively and implement corrective measures. Identify past, present and potential risks that the current project faced, facing or will face in the near future. Carefully and methodically categorize all the risks qualitatively and quantitatively and implement corrective measures. Assign one or two persons from your team as risk owners. These persons identify the risks, discuss the risks with the team and the project manager, find solutions and implement them.

10. Inappropriate skills: In this rapidly changing, technology-driven business environment and the constant changes of technology make it hard to predict skills the IT department will need. Almost all large IT projects require a diverse range of skills. Many teams lack the breadth, and depth they require.  Plan proactively for your resource requirements and make sure that everybody works under his/her own specialization. Have a solid plan for the skills your project requires. Work with your HR manager to evaluate all alternatives, which may include but not limited to hiring contractors, outsourcing, providing training to existing team members etc.

In step 2, we will discuss about communication and how to have a solid communication plan not just a strategy.

Technorati Tags: best-practices, change-management, communication, project-management

Incorporating Configuration Management on Your Project By Dave Nielsen Software configuration management is intended to control the configuration of a software product or system throughout the life cycle of the product and that includes the project that builds it. Software development organizations that have been certified as CMM or CMMI Level 2 or above will have a [...]

Last week we started a series entitled 'You Make the Call!' with our inaugural entry being an problem for a call center manager having a difficult time with their call volume. If you haven't read the original article yet, read it before you read our solution below.


Misdirected Solutions
To the call center manager, the problem was call volume. There were too many CSRs needed and as more locations came on line, the call volume would only increase. The manager's suggested solution would cut the number of calls, thus decreasing the manager's cost, but it wouldn't really solve the underlying problem. The call volume is only a symptom of the real problem which would not be solved with the presented solution.

Others might suggest that having the point of sale system in the store keep a running count of inventory level and automatically notify the online system when it has reached a stock out or reserve stock level. By doing this, the calls are eliminated and the manager doesn't need to use their time to notify a stock out, either. While this solution could work, there are two issues with it: such an integration is expensive, especially if the inventory software in the store can not keep such a running tally. Second, this also implies that when products are sold in the store that the store knows exactly which items are sold. If the store sells nails by the pound, for example, it is considerably more difficult to know exactly when the store is truly out of nails.
What Really Happened
So what was the real problem? We've been alluding to it the entire time, but the real issue here is inventory management. The store is suffering from stock outs, but no one at the store level seems to be concerned that they are potentially forgoing sales because of a lack of product. If the store doesn't have the item in stock that the customer wishes to purchase, they are potentially missing out on sales.

In this situation, you should start by enlisting the store operations team and helping them determine the exact reason the stock outs have been happening. Is the store not managing their inventory correctly? Is the incentive for the store to maintain a minimum inventory amount keeping them from being able to sell products the customer wants? Is the store intentionally not stocking certain items they don't want to sell and then repeatedly calling those products in to the call center as 'out' in order to never sell them?

Your Turn
So how did you do? Did you come to the same conclusion we did? Do you like the idea of this series? Do you have a great scenario you would like to write and present? Let us know in the comments!

Assumptions: The Elegant Risk By Abdulla Alkuwaiti Introduction If there was an elegant risk in projects, then it will be assumptions. Its elegance comes from the way how people often justify wrong assumptions that leads to risks. They often use phrases like “what can I do”, “I thought it will never happen” and “it’s impossible”. It is as [...]

CMM and Project Management - Tracking and Oversight By Dave Nielsen The goal of the Software Project Tracking and Oversight Key Process Area (KPA) is to provide sufficient insight into project performance so that the project manager can detect variances between performance and the plan and take preventive or corrective action. This KPA influences all PMBOK knowledge [...]

If a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related – Martin Shub

Why is it those starting with theory have a difficult time moving the practice. Book authors with notional diagrams, descriptions of suggested actions in the absence of real examples?

Why is it those starting with practice fail to understand their experiences may in fact be just personal anecdotes, not transferable to other domains or even contexts inside their own domain?