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

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?

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?

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

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.

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

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!

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?

I was rather shocked, and quite delighted, to get an email from Katie Clark at IDEO yesterday with several different new graphics for the top of my blog.  I didn't ask her or talk to her about, she just decided to send me some new ones because she and her colleagues at IDEO were looking at my blog and decided to try some new designs.  I feel mighty lucky to have friends who are world class designers and decide on a whim to give me presents like that.  Thanks Katie!

The new design above is the one I like best.  In the IDEO and d.school spirit, this is a prototype and I can always go back to the old design or perhaps see if you like one of the other one's better.  For starters, what do you think of the new design above?

P.S. I would also like to give a big thank you to Tim Keely for inserting the new graphic.

I have written here fairly often about research by Harvard Business School's Boris Groysberg on the virtues and limits of star employees.  One of my posts described has delightful research that shows firms should steal superstar women, not men.  It turns out that when star men move to another firm, they tend to do a lot worse in the new setting.  In contrast, star women tend to sustain their performance when they go to another firm.  Groysberg suggests this difference is explained because women are more skilled at establishing new relationships and less likely to engage in dysfunctional internal competition in their new firms.

Boris's new research is equally fascinating, a while back, he sent me an article he wrote with two colleagues called called "Too Many Cooks Spoil the Broth" (see complete reference below). They studied over 6000 industry analysts from 246 research departments in Wall Street firms -- these are people who write reports about the current and expected performance of firms, and who specializes in particular industries. Their reports predict future earnings for companies and contain recommendations about whether to buy or sell stocks.  As Boris and his colleagues show, some of these analysts are stars, selected by the Institutional Investor as being the top person in their industry and being picked as a star is worth hundreds of thousands of dollars in compensation.  The results of this research are interesting because, while some leaders might think that there is no such thing as having too many stars, Boris and his colleagues found a curvilinear relationship between the number of stars in a group and overall performance -- so, having a few stars help, have a few more doesn't hurt (but doesn't help), but groups reach a tipping point where too many stars seem to dampen performance. 

Groysberg and his colleagues suggest that the "too many cooks" problem happens because partly because, when a group is filled with individual stars, the dynamics degenerate because people devote excessive attention to the the internal status game and competition and hesitate to share information that may help the group as a whole, but will threaten their standing in the group.  In other words, when there are too many stars, people focus on what is best for themselves, see other top performers as people who are in the way rather than people they should help, and the overall performance of the team seems less important.

This is just one study, but a quite rigorous one one.  And it adds for evidence to the claim that Jeff Pfeffer made in the The Knowing-Doing Gap that dysfunctional internal competition is one of the most vile impediments to turning knowledge into action in groups and organizations.  Once the game becomes "I win when you lose," the team or organization suffers.

Here is the complete reference: Groysberg, Boris, Jeffrey T. Polzer, and Hillary Anger Elfenbein. "Too Many Cooks Spoil the Broth: How High Status Individuals Decrease Group Effectiveness." Organization Science (forthcoming). 

Here it is: my latest presentation. Five days of work, 38 drawings, 14 photos, 81 slides, and plenty of texts, to be delivered for the first time at the Scrum Gathering in Orlando next week.

The Dolt's Guide To Self-OrganizationView more presentations from Jurgen Appelo.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Self-Organization vs. Emergence
Self-Organization vs. Evolution
Self-Organization vs. Anarchy

by Timsamoff

Even if you believe that everything from dating to contact with God can be managed on the computer, that ain’t quite true. Despite the push for technology in every operation–and despite our first endorsement of (still-sequence) video-conferencing (VC) in a 1983 book, you will want or need to meet face-to-face at times. The message itself will determine. Caution: Don’t believe the opinion-mantra, “It’s gotta be face-to-face.” It ‘don’t gotta be nuthin’ but proper. ‘Proper’ requires thought. Meeting settings must be proper for given messages. Meetings such as skill training are best done in small groups. Military ISD (our source) presents an algorithm for settings-selection.

Every meeting-support technique has strengths and weaknesses; and one of those choices will work better for your meeting than will any others. Selected options by purpose, not dart-throwing. For key tools (pro & con) that can be used to support your message, check a reprint of our ’70s article for basics; slight augmentation needed now. See the original article on our website: click ‘Recognition/Industry’; below Note: ‘AOM & Early Mag Articles’; see article from “Advertising & Sales Promotion” magazine (web p8 of 22pp).

Specifics there are valid unless noted here:

Re: Charts, drawing, chalk-/chem-boards: Verbatim, plus: Computer-aided visuals, now.

Re: Photographs: Verbatim, plus: Also computer-aided visuals, now.

Re: Books, booklets, outlines, tape recordings or disks: Verbatim, plus: Again, computer-aided visuals, now.

Re: Demonstrations and sociodramas (constructed plays, not believed):  Verbatim, plus: Less convincing if computerized.

Re: Role playing: Verbatim, plus: Valid only if live, not computerized.

[Quoted further]: All of the above tools [in the entire original article] have intrinsic value of either a permanent or intermittent nature. By contrast, visual aid equipments are enabling technologies but have no independent value whatsoever! Today’s purveyors have neglected to mention your non-technology options. [End reprint.]

Three significant points:

1. The computer is extremely valuable, of course. However, the eye does not prefer, or distinguish between, the sources of usable graphics. Therefore, slides and printed materials are still valid.
2. All graphics, no matter how simple or complex, must appeal to participants’ understanding of your message’s basic concept (right brain)…to interpret, as a further explanation of the spoken/written words. On-screen words (left-brain) are not legitimate visual ‘aids’ unless the words themselves are at issue. That’s rare. Color is not essential if the graphic itself is clear. (For multiple US military findings: ‘Recognition/Industry’ button, below Note; see “FirstTake” magazine (p13 of 48pp).
3. In meetings/seminars/training, etc, eye cloys more quickly than ear. For long presentations of non-technical material, ear is the preferable recipient. Complex/technical stuff needs visual help.

Decide which of the article’s techniques best suits the purposes and requirements of your message; select the proper support materials and technologies; determine the proper setting for the message, purposes, and audience size. Proper settings might include hotel space.

Audience size is a factor. Don’t guess according to general crowd-control principles: Best size for the meeting purpose, time allotted, and optimum use of likely setting? Military ISD algorithms work well.

You can’t coach a roomful of people in any but a cursory way. Adequate? If not, how enhanced? Smaller break-out sessions suffice? Can/will managers supervise, back at offices? Enough authorities to run multiple break-outs? If not, don’t fake it! Choose: one central session or multiple regional repeats?

Every meeting-caller usually wants to reach everyone in his/her target audience simultaneously. Great, if simultaneity is a valid factor. Bad, if it causes unnecessarily-large convocations. Large meetings feed on their own size and thereby cause additional expenses.

Decades ago, American Express found about two-thirds! of the average corporate travel budget consumed by annual central sales meetings. Computers can change that somewhat: Significant savings are possible via Video Conferencing. Computer programs suffer drop-outs–just like schools or sleepers in central meetings. Also decades ago, “Sales & Marketing Management” magazine’s  ‘Survey of Selling Costs’ (annualized) found multiple regional sales meetings always to cost less than one central meeting.

Unless simultaneity is essential, hold regional meetings whenever possible. That’s more demanding of meeting-caller time, short-term, but it’s also less pressured: Local offices can usually handle most or all logistical needs.

Although computer software now allows collaboration among editors and other specialists, software enables only editorial ‘collectivizing.’ Expertise and authority are NOT created by collaboration–that’s round-table discussion from distant chairs. It does save time and travel.

Many meetings can be held in-house. Choose smaller regional facilities if you hope to avoid in-house interruptions. To manage any such meeting, embargo all phone calls, in or out. You might permit exceptions for the Chairman of the Board and CEO, but only if you value your job.

If you agree on anything with a hotel rep, get everything agreed in writing. All chains and most large facilities have an “in writing only” policy in case of disputes…common when any third party over-stays its allotted time and delays your set-up or scheduled session.

Selected reprints from “AOM” were Copyright either 1970-71, Crain Communications; or 1971-1973, “Sales Management” (later: “Sales & Marketing Management”) magazines.

For more information and a proved form for comparing criteria and selecting hotel facilities, see our website: www.meetingsCavalier.com. Click on ‘Business Writing’; then ‘Titles’ button. At book “Sales Meetings That Work,” click on ‘Chapter 18,’ complete segment. Dow Jones-Irwin’s “SMTW” cover shows under ‘Recognition/Industry’ button.

In order to have a “happy project,” a software project manager should respect the flow of the stakes…

• Stakeholders have stakes.
• Stakeholders communicate their stakes by expressing their expectations, which are more formally defined by means of requirements to the process or product.
• Project management should make every stakeholder a winner by accepting and inventing requirements that continually satisfy the stakes of individual stakeholders and do not conflict with the general process or the product.
• Project management should give continuous feedback to the stakeholders on the state of the stakes.
• Based upon this feedback, the expectations and requirements might change, and in this way a new cycle begins.

Easy as pie.

Other people who liked this article liked these too

• Why Soft Skills Are Essential To Project Managers
• The Four Dharmas Of Project Management
• Marketing: Tech People Hate It. Boy Are They Going To Need It!

Join the ProjectShrink Facebook Fanpage!

The Flow of the Stakes

Ron Rosenhead has a wonderful post about "two project teams." Ron suggest, through an article he read, that a second team could

• Check out whether the risks are too great or acceptable
• Develop a business case for or against the project
• Identify whether there any project benefits - what they are and whether they are achievable
• developing a plan identifying resources required and how this will impact on other projects and business as usual
• Identify whether you have sufficient resources of the right caliber
• Check is there is a link back to the company strategy

Not all these are direct activities of PP&C. But the organization where PP&C typically lives - Finance and Business Operation (F&BO - say that fast 5 times to get the gist of our status) - does have this accountability.

F&BO includes PP&C, Contracts, Subcontracts, Procurement, and things like that.

These activities provide an external assessment of the project's performance through the "planned" performance compared to the "actual" performance. Earned Value is of course the basis of this assessment, but there can be other simpler assessments as well.

You planned to have 20 tables in the database done, by the end of the week (all of equal effort) and you got 18 of them done, you're 90% physically complete.

When you separate the "doing" from the measurement of the "doing," you start to establish credibility for the work being performed in ways you can't when they are not separate.

by Rutty

The sales-oriented, over-use of ‘maxi-media’ (anything in excess of need) was first challenged by me in two columns (1970-71; 71-73) and my first book (1973). A worthwhile message will be listened to and needn’t be prettied-up. Just make it intelligible when heard. “You can put lipstick on a pig, but. . .” Complex messages can be helped only by visuals that help clarify concepts, not illustrate irrelevancies. Pretty-for-the-sake-of-pretty detracts from message.

Old learning? Well, the human brain hasn’t changed much in 10,000 years, according to scientists; so the researched educational principles and findings are still valid. New research on the brain in recent years has identified specific real estate where various brain functions occur. We newly know that the brain has a life-long plasticity and can reassign real estate according to new-learning demands or to compensate for injury.

New proofs of old practices, too: Sleeping on new-learning material can aid retention. New idea? Ask any HS or college student who crams late-night for morning tests. Now we know why it works.

Vicarious practice has long been known to work. Newly-discovered reasons: ‘mirror neurons.’ While watching others, our empathic neural system ‘operates’ inoperatively in muscles, responding to observed action. New understandings of ‘old’ learning. Scientists still haven’t discovered how the functions do in fact function: How and why does consciousness occur?

Meanwhile, you’ll need old and proved learning and research. So return to learning needs:  In specific instances, technology can help in specific meeting/training situations. Don’t rush. ‘Be the first on your block’ to introduce new technology into the meeting room–is for kids. Other-directed meeting-callers have depended on technology and advertising claims to make their decisions and cases–and lost. Technology can’t make decisions. ‘Computer-aided-everything’ is a profitable sales idea–but first pay attention to the ‘aided’ element of the phrase. Aids-choice requires authoritative knowledge of message. Military ISD offers algorithms.

Don’t start with hardware! Increased comfort-of-viewing underlies most A/V technological advances (other than the computer itself). As an element of the surround, comfort contributes only incrementally to learning: unmeasurable in most company circumstances and probably not worth the added time or effort.

To select the proper technology to help deliver your message, first determine what specifics must be delivered in your current or next meeting/training session. For help on this “message” topic, see our prior Blogs.

Next, determine what categories of tools and A/V would aid in making your message and objectives clear to meeting/training participants. Such categories include new tools, prototypes, samples, demonstration/taste/ feel, case histories…and technology, including simple slides. Non-commercial exhibits present unspoken visual comprehension.

Remember: a computer-and-screen is only a fancy chalkboard. New chalk-boards are blank. Ditto, new computers. You enter meaningful material onto blackboards; guess what.  Absolutely nothing can do absolutely everything. Nor can anyone! You need real help based on facts, cases, and qualified opinions. Those are few.

Some books offer chapters prepared by numerous recognized authorities. Yet, no matter how valid the individual chapters, they usually don’t add up to cohesive, workable systems. If books on meetings topics were/are discursive, readers must cut-and-paste into probably-inadequate meeting planning structures. Does the given book present a workable system?

Magazines love tips: they’re plentiful, easy, short, and perfect for filling unused space. Readers cut-and-paste. No system. In short, ersatz “help.” They can’t photograph or sell you your own message. There’s a paucity of worthwhile information in even business journals. Their editors usually defer to the meetings industry press’ editors and viewpoints, because “Don’t they know best?” Obviously not!

The original concept and title we created for “Achieving Objectives in Meetings” has become a standard concept in the meetings professions and essential trade(s). ‘Achieving objectives’ as a communications key is finally being rehabilitated (in different words) by industry-associations that have previously down-played that concept.

Meetings can be improved significantly without extravagant spending when the methods and technology used are chosen with concern for–and protection of–intelligent, do-able messages, aided by proper tools and practice. Aided–not necessarily ‘technology-aided.’

Message-control is free; it’s based on brain, not budget! Now, how much more attention can you pay to the message?

For citations of ignored fundamental research, see wwww.meetingsCavalier.com; then ‘Business Writing.’ At ‘Recognition,’ button, see our bibliography for ‘A&SP/Granddaddy’ button (at base of Note): It’s proof that useful research was long available.

For later presentations of useful specific research findings, largely military, see ‘Recognition/Industry’; then “FirstTake” magazine (p13 of 48); and also ‘AOM & Early Mag articles’ button.

For comprehensive information and procedures re: meetings needs and aids, you might see our “Sales Meetings That Work.”

For hotel-related methodology, see tomorrow’s blog.

“Here I am, brain the size of a planet and they ask me to take you down to the bridge. Call that job satisfaction?”

Do you know this quote? If you do, we have something in common, we both like the “Hitchhikers Guide To The Galaxy” enough to know some of its text by heart. I would even assume we have a similar taste of humor.

When interacting with people you have just met, you can use this mechanism. Drop a quote from your favorite movie or book, and see if people respond. If not, that’s fine. If they do know its origin, you just created a short cut to connecting on a more intense level. You just established that you are both “the same”. At least, for some part.

Dave Prior and I discussed the use of verbal clues, or tokens as he calls them, in the second part of our recent podcast.

It’s about using quotes, or language in general, as a kind of “social marker“:

““Social markers” is a term created by Hugh MacLeod whose blog, GapingVoid, defines social markers as “ a prime form of social shorthand, that people use to STAKE OUT the ecosystem they’re occupying”. A brands social marker can be either good or bad. It is tagged by the conversations of those that have experienced the brands product, service or culture.”

By dropping “social markers” you give “your kind of people” an opportunity to identify themselves.

It’s not limited to language. You might wear a hat. Or even a duck, as Havi Brooks explains:

“I have a duck. I am a biggified blah blah expert whose business partner is a duck.
People who get it and think it’s cool are totally in.
People who think it’s stupid, or suspect that she’s — ewwwwwwwwwww — some kind of marketing ploy, are out. But not because I have to ask them to leave or anything. They just self-select out. They don’t stick.
Having red-velvet-rope Selma around (and let’s be honest, I don’t do anything without her) turns out to be a great way to help people find their way in or out.”

The use of social markers is something that fascinates me. It’s useful to anyone working for short periods of time with people they don’t know and might almost have no authority over.

Other people who liked this article liked these too

• Three Sphere Project Management: Using All 3 Parts of Your Brain
• Project Shrink Birthday Party
• MP3 Interview With Alistair Cockburn

Join the ProjectShrink Facebook Fanpage!

Social Markers. Here I Am, Brain The Size Of A Planet.