Innovation: The Missing Ingredient (Part II)

In Part I of this post we analyzed the historical evolution of the project management discipline and its contribution (real or perceived) to the practice of managing projects. Now, let's look at the role innovation plays in managing projects.

ANALYSIS
But before doing that, let's try to define the perceived value of a project in the customer's eyes:
• effectiveness = the measure of a project delivering the expected product (physical good, service, or result)
• efficiency = the performance with which a project delivers a product
• involvement = the degree with which a project involves its stakeholders; implies communication and collaboration
• innovation = the degree with which a project involves creativity in the development of the product
• agility = the degree of the project's ability to adapt to internal or external changes

Perceived value = f(effectiveness, efficiency, involvement, innovation, agility)

So, back to our quest, how did the evolution of project management affect these factors?

Historically, we gradually moved from an undifferentiated, undefined, and ad-hoc approach to a differentiated, well defined, and standardized approach.

On the positive side, this change has the general effect of increasing effectiveness, efficiency, and involvement. Unfortunately, on the negative side, it also has the effect of decreasing innovation and agility.

In principle, we can say that the differentiation and standardization of PM, BA, and SE taking place over the last decades has the unfortunate side effect of squeezing out the creativity and innovation. Often, this resulted in reducing agility as well.

Even when innovation is still "employed," it stops short of delivering what it had promised. That is because we tend to focus only on “sustaining innovation” (step-by-step innovation; as often reflected, for example, in Six Sigma approaches) and stray away from “disruptive innovation” (leap innovation and the main condition for a breakthrough solution). This, in turn, is due to the false perception that “disruptive innovation” is unpredictable and cannot be controlled or managed.

So, where do we go from here?
In order to re-employ creativity and innovation for delivering breakthrough project solutions, we need to:
1. consider the role that creativity and innovation play in analyzing challenges and designing, developing, and delivering solutions
2. incorporate both sustaining and disrupting innovation
3. define the right conditions/environment to facilitate innovation
4. define and assign a role for owning innovation work
5. determine the necessary knowledge and skills to fulfill that role and find ways to develop them
6. finally...set up an action plan to implement all these changes

To do so, here is a sample of the questions we'll have to address:
• when should we employ innovation? how?
• who has the best opportunity to do it?
• who is the best positioned player to do so? what would their responsibilities be?

But that's my topic in the next article. In the meantime, please post your comments.
Thanks.

Balancing Agility and Discipline

I just finished reading Balancing Agility and Discipline by Barry Boehm, director of the USC Center for Software Engineering, and Richard Turner, one of the creators of CMMI. I like the pragmatic tone of the book, its structure, "day in the life" pictures, case studies, and conclusions. Yet the authors indulge some Agile misconceptions and their case is riddled with straw man argumentation.

Right from the start they set up a false dichotomy between agility and discipline, as if Agile is not a discipline or not disciplined--the authors define discipline as "process mastery, preparation, and courage." Agile done right is all this. And who hasn't seen undisciplined "discipline" (process-heavy approaches is what the authors intend here).

The key to success, they argue, is balancing agility and discipline--what Agilist wouldn't agree?--by using their "risk-driven approach" as a "pragmatic means of reconciling the strengths and weaknesses of disciplined and agile methods." This requires assessing project personnel, criticality, size, culture, and dynamism to customize an agile-discipline hybrid that minimizes risks.

Most Agilists I know are pragmatists, not purists, and do, in fact, use hybrids as needed. The "risk-driven approach" advocated here is a helpful way to quantify the risks and work towards a hybrid. But one caution: "Balancing agile and plan-driven methods requires exceptional people." Agreed, and the authors admit that because you need, and therefore find, more exceptional people in an Agile environment, you're more likely to find success by scaling Agile up than by paring plan-driven methods down.

Other helpful points of clarification for "the perplexed:"

• Agile is an "adaptive rather than predictive mind set."
  
• "Agile is `planning driven,' rather than `plan-driven.'"
  
• Agile defines quality as customer satisfaction vs. "specification and process compliance."
  
• Agile's rapid growth and adoption is due to today's dynamic business environment and to "the resurgence of the philosophy that programming is a craft rather than an industrial process"
  
• "Personnel turnover is a project's number one risk."
  

Examples of straw man argumentation:

• "The approaches have become adversarial." I've seen some healthy debate but most practitioners are looking for common ground.
  
• "The primary difference between agile and plan-driven development practices deal with the design and architecture of the software. Agile methods advocate simple design, one that emerges as functionality is implemented." The authors spill a lot of ink demonstrating that simple may not be sufficient. Yet just a few pages earlier they point out: "Agilists speak of a `mentality of sufficiency'--doing only what is necessary." "Simple," then, actually means "sufficient" to the experienced Agilist.
  
• The authors point out that Agile refactoring risks turning into costly redesign. And a plan-driven approach, where quality is defined as compliance to outdated specs and rework is common, improves on this how? Later they admit that Agile done right looks at each user story in context of the big picture.
  
• They complain that getting all the stories done and integrated--particularly "tasks that fall between story cards"--often requires "police" action that "conflicts with agile philosophies." What they call "police" action I call "management" action and, yes, I admit that management action is often required, agile or not.
  

All in all, the book is recommended as it adds to the conversation and moves it in the right direction: whatever works, because we've got work to do!

While I'm at it, this week I also read the results of an IDG Research report that says innovation is critical to the future success of 44% of companies yet only 14% are, in fact, innovative. 42% say technology is the key to innovation. Yes and no. Technology is an enabler of innovation but innovation itself is a discipline, as I’m currently learning in Peter Drucker’s Innovation and Entrepreneurship.

My Vision for IT...

...because you asked, and in this order:

1. Business People
“The only differentiator of great companies is great people.” (Jim Collins, Good to Great)
Attract, develop, and retain the “right” people:
• Business people first, technicians second
• Actually care, want to make a difference
• Always leaning and growing
• Team-oriented, trustworthy
• Demonstrate a bias for action and results
• Entrepreneurial, creative, energetic
• Have fun!
Personal management style is Situational Leadership: one size does not fit all.

2. Business Processes
Bottom-line growth
Looking for cost savings / battling Parkinson’s Law
Business / Workflow Process Management & Value Stream Engineering
What can we do to add value? What can we not do to add value?

3. Business Services
Tactical:
• Stability, security, and efficiency of business infrastructure and operations (ITIL)
• Risk Management, Business Continuity & Disaster Recovery Planning
Strategic:
• Enterprise apps (ERP, CRM, Master Data Management)
• Virtualization, cloud, SaaS technologies
• Mobile and thin clients
• Open source

4. Business Information
Business Intelligence 2.0
Web 2.0 and collaboration tools (SharePoint)

5. Business Innovation
Top-line growth
Driving revenue and improving our value proposition
New products / services / markets / channels / customers
Agile project management and software development
Change Management

6. Business Results
Portfolio Management
Organizational (vs. individual) accountability, goals, and metrics
Customer Satisfaction

Innovation & Two-Pizza Teams

There’s a flurry of new articles at CIO.com on one of our favorite topics around here, innovation. ‘What Your Team Can Learn About Innovation from The Simpsons’ was the keynote delivered at a recent Red Hat Summit by Joel Cohen, writer and associate producer for The Simpsons. Some of Cohen’s tips for encouraging innovation: team autonomy, a “culture of brainstorming” and looking for potential even in the bad ideas, and diversity. It’s worth a read.

'Can Big Companies Innovate?’ prompted a reader’s observation that “the anthropological concept of ‘ten-groups’” seems to be at work in the fact that smaller companies are more innovative. I wasn’t familiar with the “ten-group” concept so I followed his link to a blog piece entitled ‘If you’re working in a big group, you’re fighting human nature.’ It’s a great discussion on the increased productivity you get with “ten-group” and “two-pizza” small teams. (Of course, there’s a fair dose of hilarity on the correlation of team size to pizza consumption!)

From there I surfed over to a FastCompany.com interview with Amazon founder Jeff Bezos where he talks about building the company around “two-pizza” teams, a must-read article by software guru Paul Graham called ‘You Weren’t Meant To Have A Boss’, and a reference to a discussion about all this in Malcolm Gladwell’s The Tipping Point.

Happy reading! This ought to keep us busy for awhile.

On a separate but related note, I just saw some stats demonstrating that the larger the project the more likely it is to fail. No surprise here. Even the smallest of projects had about a 54% chance to succeed and from there it was a straight line down to 0% on projects over $10M.

All of this (innovation + small teams + small projects) adds up to one thing in my vocabulary, Agile!

Software Development and Creativity, Marketing IT, and Offshoring Redux

The June 2008 issue of PM World Today features a paper by Aleksandr Tarabykin called ‘Extreme Programming (XP) for Better Results.’ He reports on the findings of a recent study at JP Morgan Chase: XP reduced defects by 63%, critical defects by 79%, while development time was reduced 47%!

On a related note, the June 2008 issue of Communications of the ACM includes an interesting article entitled ‘Software Design and the Monkey’s Brain’ by software guru Robert Glass. The bottom line is that software development takes place “at the speed of human thought” and is more hindered than helped by standardized processes and tools. That led me to Glass’s book Software Creativity 2.0. On his blog, speaking of the book, Glass says:

“There's a fundamental conflict in the software world, sometimes taking on the attributes of a war. On one side, managers search for ways to impose more discipline and control on software builders, and researchers advocate and sometimes seek to mandate formal methods for the same purpose. On the other side, software builders quietly continue to build software pretty much the way they always have, with freewheeling methods and creative solutions…The key issue underlying this conflict, I believe, is creativity. If there is little or no need for creativity in building software, then those managers and researchers are right in what they advocate--we can simplify and routinize the work of software. If, on the other hand, creativity is and always will be an essential part of software construction, then those practitioners are right--we will continue to need freewheeling methods and creative solutions. It is this whole collection of issues, standing on this foundation of software creativity, that I hope to address, and perhaps to resolve, in this book. That's why the book is called Software Creativity.”

This one’s definitely on my must-read list.

A couple other pieces in Communications of the ACM are relevant to ongoing discussions here. ‘Give Me Information, Not Technology’ is a great piece by professors Arik Ragowsky, Paul Licker, and David Gefen on how IT leaders might address the declining perception of the business value of IT. Here’s the heart of the matter:

“Consider how a business organization approaches its potential customers. It typically employs marketing specialists to conduct market research, aiming to identify what drives and excites their needs, as well as how much they are willing to pay for products and services (perception of value)…Only after the market is understood…are R&D specialists assigned to work on products. Likewise, only after first ‘studying’ their customers should IT ‘marketing’ personnel (business analysts) transfer their finding to IT R&D specialists (designers and programmers)…”

Good stuff.

Finally, in ‘A Risk Profile of Offshore-Outsourced Development Projects,’ professors Charalambos Iacovou and Robbie Nakatsu report that eight of 10 offshore projects go bad, and they give us the top 25 reasons why. To give you the list would constitute a copyright violation but I will summarize the top 10.

Three are management issues: successful offshoring requires hands-on management from the project to senior levels. Three are communications related: don’t underestimate the challenges of managing expectations all around. Two are business domain problems: offshore personnel do not know your business so subject matter experts and end users must be involved. This, of course, is not unique to offshoring but is exacerbated by the management and communications issues. One is a technology surprise: don’t assume that offshore resources have the expertise and experience needed to execute. And the last one is financial: the total cost of managing all the above is more than anticipated.

This might be my last post for awhile. The next several weeks are BUSY!

The Agile Way!

I'm often asked what it means to say that my teams work the "Agile way." So here are the principles by which we live or die:

INTENSE FOCUS ON THE BUSINESS

• NO BUSY WORK ALLOWED! Non-value-added work? Stop it NOW!
• The Pareto Principle applies to software development! (Think about MS Excel.) 20% of features deliver 80% of user value. 45% of features are never used! 80% laser-focus on the 20%!
• Every day ask yourself THE BIG TWO QUESTIONS! “What can we do today to add value?” “What can we NOT do today to add value?”

1. Does this activity or deliverable DIRECTLY add to the top line (revenue generation) or bottom line (cost savings)?
2. Does a REAL customer want it enough to pay for it?
3. Does someone REALLY need it to get the job done?
4. Will we REALLY need it next week? Next month? Next year?
5. How can we do it faster, better, cheaper?

• A lean mean software development machine doesn’t…

1. Define more process: unless you can prove it adds value as defined above.
2. Write more documentation: unless you can prove it adds value as defined above. Can it be communicated face-to-face instead? If not, KISS (Keep It Simple and Successful) IT. If the customer’s not using it AND we’re not maintaining it, KILL IT!
3. Code more features.
4. Sleep at night if the code is buggy or sloppy: STOP. Clean up after yourself. NOW. Refactor. Go back to sleep!
5. Pogo from task to task or leave work partially done: FOCUS on one thing at a time.
6. Wait: Waiting is a black hole. It SUCKS value.

• All work must be tied to specific customer deliverables.
• Just adequate. Just in time. Just right. Just do it.
• Job #1: execute (business strategies) or be executed!
• "Demand for limited resources (think time, money, etc.) eventually matches/consumes/exceeds supply, and efficiency of resource utilization increases as supply is exhausted." Think gasoline, or water, or the fish that grows to the size of the tank. What are we doing or NOT doing to slay Parkinson's Dragon TODAY? Rationed Resources = Constrained Supply = Increased Value. (Open Source all the way!)

INTENSE FOCUS THE PROCESS

• We incorporate critical chain / theory of constraints concepts such as buffering, as well as PERT estimating to size the buffers.
• The Plan = The Scaffolding. Get it out of the way as soon as possible.
• RIP (Rapid Iterative Prototyping) it! Deliver something, ANYTHING, every 30 days! Get it right the second time!
• We LOVE speed because first to market wins!
• “Variation and change in a dynamic system is necessary and pre-determined (vs. random) by initial conditions and constraints” (Chaos Theory). We LOVE change because a stable system is a dying system!
• Design as late as possible. Develop as fast as possible. Deliver as soon as possible. Document afterwards—if you insist.
• Build to yesterday’s specs = No Quality; Build to tomorrow’s estimates = Poor Quality; Build to today's expectations = Good Quality (Job #2)
• Test first. Test always. (Tests = Requirements.) Automate testing.
• Remember Occam's Razor? "Entia non sunt multiplicanda praeter neessitatem" = "Entities should not multiply where not necessary" = KISS (Keep it Simple and Successful)! = minimalist approach to meetings, presentations, documentation, design, code, everything!
• You build it, you own it, you maintain it: documentation, code, whatever.
• NIP problems in the bud! Stop everything, brainstorm causes, five “why?” to root causes, take immediate corrective actions, get over it, move on.
• Agile all the way!

1. Small teams, shared space, customers included
2. 30-day Sprints (incremental releases vs. big-bang)
3. Test-first development
4. Timebox everything
5. Single-tasking vs. multi-tasking
6. Daily Scrum meeting, no afternoon or Friday meetings (except Scrum)
7. Status Reports? Daily = Scrum minutes, Weekly = Burndown charts, Monthly = Velocity reports

INTENSE FOCUS ON THE TEAM

• “The only differentiator of great companies is great people.” (Jim Collins)
• Hire only the best and the brightest. Turn them loose. Get out of the way!
• There’s no “I” in team! “We” share the credit when things go well and “we” share the credit when things go bad.
• Team (vs. individual) performance reviews based on business results and 360-degree feedback.
• You create your own reality. Define your own processes, estimates, commitments, etc. No excuses.
• Work hard, play hard, HAVE FUN at the great game of business! It's not about working harder, it's about working smarter.
  

While I'm at it, you might be interested in a good online video presentation by Agile guru Jeff Sutherland called The Agile Enterprise: Real World Experience in Creating Agile Companies. I'm fortunate to say that not only is my team Agile, my company is also going Agile, as are others such as GE, Sony, Wachovia, BellSouth, Microsoft, Google, and Yahoo.

Jeff also touches on our previous post about outsourcing / offshoring. While the research shows that it just doesn't work well in reality, emerging research suggests that it works well after all with Agile vendors. He's got a pretty convincing case study from an eastern European company called Exigen--and they're even CMMI level 5!

Innovation: The Missing Ingredient (Part I)

HAVE YOU NOTICED?
Project management’s main purpose is to create new, or enhance existing, products and services. And we all know that in today’s intensely competitive environment, innovation is more important than ever. Yet, in almost all projects, nobody seems to be responsible for employing and managing creativity and innovation. As a matter of fact, there is almost no reference to creativity and innovation in either the PMBOK (1), or the BABOK (2), or the SWEBOK (3)! Is this a paradox?

THE HISTORY OF HOW WE GOT HERE
In order to understand the current state of affairs, we need to look at the historical evolution of managing projects, following three different tracks.

1. The Project Management (PM) track:
We have managed projects throughout human history (4). Some were simple and small, others were large and complex (e.g. the building of the Giza pyramid, the Great Wall of China, or the many Duomo cathedrals in Italian Renaissance). While the results of these projects were often impressive, our human resources, costs, and the time required to complete them were staggering (thousands of workers, decades of years, and unmeasurable financial costs by any contemporary standards) (5).

In the 19th and early 20th centuries, we had to learn to control project costs and schedules and, as a result, we gave birth to a new management discipline, Project Management. In the 1950s, we went a step further and the modern project management era was born, with the development of new PM methods, tools and techniques (e.g. Gantt charts, Work Breadwown Structure (WBS), and Activity Network diagrams, etc.)

In 1969 we formed the Project Management Institute (PMI), with the mission to define and standardize our new PM profession. In 1987, we published the draft version of the Guide to the Project Management Body of Knowledge (PMBOK), our bible for PM. Further revisions/versions were released in 1994, 2000, and 2004, with the latest version scheduled for release later this year (2008).

2. The Software Engineering (SE/SDLC) track:
From the late 1950s through the 1990s, due to the fact that computers started to have a rising impact on business projects and operations, we (the computer industry) began defining the Software Engineering profession. In 1998, sponsored by the IEEE Computer Society and the ACM, two of the major players in this domain, we started work on the development of the Guide to the Software Engineering Body of Knowledge (SWEBOK). The guide was released in 2004. One knowledge area we included in the SWEBOK was Requirements Engineering, an area that, now, we think better described as Software Systems Requirements Engineering.

WARNING!
1995-2004: Standish Group reported several studies in which the results indicated two main reasons for IT project failure: project management and requirements management. Often, the two take turns being the number one reason.

3. The Business Analysis (BA) track:
In 2003, in response to the growing concerns over requirements reported in the Standish Group studies, we formed the International Institute of Business Analysis (IIBA), with the mission to define and standardize the profession and practice of Business Analysis. However, we took a new approach defining this profession by encompassing all business and enterprise activities (e.g. enterprise analysis, business and systems requirements, etc.) that we undergo to develop both business and technical solutions, not just the activities involved to develop and manage software systems requirements (as already defined in SWEBOK). In 2005, we released our first Guide to the Business Analysis Body of Knowledge (BABOK), with further revisions in 2006, and a new version due for release later in 2008.

How have these developments shaped the way we manage projects today? How do customers and project teams perceive the value of these changes? And, furthermore, what happened with the Innovation component?

We’ll analyze these questions (and more) in Part II of this blog.

References:

1. PMBOK = The Guide to the Project Management Body of Knowledge, published by Project Management Institute (PMI), http://www.pmi.org
   
2. BABOK = The Guide to the Business Analysis Body of Knowledge, published by International Institute of Business Analysis, http://www.theiiba.org
   
3. SWEBOK = The Guide to the Software Engineering Body of Knowledge, http://www.swebok.org
   
4. Great and Significant Historical Projects from the Past, http://www.lessons-from-history.com/
   
5. Project Management - History of Project Management, http://www.referenceforbusiness.com/encyclopedia/

Lean Software Development

I’m reading Lean Software Development by Mary and Tom Poppendieck. So far, it’s the best I’ve read on software development, and I read a lot. Mary spent a number of years at 3M in software engineering before moving into manufacturing management, then product development, and finally back to software engineering. In the preface she writes: “I was appalled at what I found when I returned. Between PMI (Project Management Institute) and CMM (Capability Maturity Model) certification programs, a heavy emphasis on process definition and detailed, front-end planning seemed to dominate everyone’s perception of best practices. Worse, the justification for these approaches was the lean manufacturing movement I knew so well.”

“I was keenly aware that the success of lean manufacturing rested on a deep understanding of what creates value, why rapid flow is essential, and how to release the brainpower of the people doing the work. In the prevailing focus on process and planning I detected a devaluation of these key principles. I heard, for example, that detailed process definitions were needed so that ‘anyone can program,’ while lean manufacturing focused on building skill in frontline people and having them define their own processes.”

“I heard that spending a lot of time and getting the requirements right upfront was the way to do things ‘right the first time.’ I found this curious…[at our plant] the idea of freezing a product configuration before manufacturing was simply unheard of…”

“Detailed front-end planning strikes me as diametrically opposed to lean manufacturing principles. Process definition by a staff group strikes me as diametrically opposed to the empowerment that is core to successful lean manufacturing…It seems to me that CMM, in its eagerness to standardize process, leaves out the heart of discovery and innovation that was the critical success factor in our move to total quality management…”

“It seems to me that a PMI certification program teaches a new project manager several antipatterns for software project management. Work breakdown. Scope control. Change control. Earned value. Requirements tracking. Time tracking. I learned all about these when I was a program manager for government contracts at 3M, and was keenly aware of the waste they added to a program…”

“If you think that better, cheaper, and faster can’t coexist, you should know that we used to think the same way in the pre-lean days of manufacturing and product development. However, we learned that by focusing on value, flow, and people, you got better quality, lower cost, and faster delivery…”

Amen Mary! More to come in future posts.

While I'm at it, this week I attended a meeting of the Society for Information Management's NC chapter. If you are a CIO or direct report of a CIO, you definitely want to check out this organization.

Ground Rules and the Social Contract

There’s an old adage on teamwork that says “first field a team, then become a team.” Fielding a team takes some work, becoming a team takes a lot of work. Bruce Tuckman taught us years ago that good teams don’t just happen, they’re made. One of the most important jobs of any leader is to make sure your team becomes a team. I’ll have more to say on this in future posts; for this post I focus on the importance of ground rules.

As Abraham Maslow taught us, a sense of human bonding and belonging is a basic human need. Good teams are communities in miniature. The more successfully you facilitate and nurture this sense of community, the more productive your team becomes and the less likely they are to fragment under pressure. And one of the most important things you can do to maintain this sense of community is to maintain the social contract that helps hold together every functional community—Thomas Hobbes, John Locke, and Jean-Jacques Rousseau taught us this one. Ground rules constitute the social contract for your team.

“But we don’t have ground rules,” someone will say. Of course you do. Every team has ground rules, whether they’re explicit or not. And the more culturally diverse your team (I’m a strong proponent of diversity!) the more explicit your ground rules need to be.

I’ve managed global teams and turned up for meetings in places where on-time meant I was 20 minutes early. On more than one occasion I’ve been told, “uh, I don’t work with women.” (Huh?!) I remember one project where the Engineering folks just couldn’t understand why the Sales and Marketing people couldn’t get to work “on time” every morning like they did. On another project, we actually brought in a consultant to help us figure out why the people from down south and the people from up north couldn’t get along. “It’s a no-brainer,” he said. “The people from down south are too laid back. They need to be more assertive and speak their mind.” The consultant was from Boston. Had he come from Atlanta he might have said: “It’s a no-brainer. The people from up north are too aggressive. They need to chill out and shut up once in awhile!” We’ve got to figure out how to work together, and the sooner the better. Good ground rules head off such cultural differences and help move the team more quickly through forming and storming to norming and performing (Tuckman).

“So how do I go about determining the law of the land?” Well, what kind of community do you want? You could dictate the law top-down, and sometimes that is appropriate (“uh, I don’t work with women”). Everyone should be very clear on corporate values and ethics. Beyond those boundaries, however, you’ll get the most buy-in and commitment from your team if you operate in a more democratic fashion.

What I do not recommend is the oft-seen, flippant approach that says, “Okay, we’ve got to come up with some ground rules so let’s brainstorm for five minutes and call it good enough!” What I do recommend:

• Use a Delphi-like technique where everyone anonymously contributes a list of things they like and a list of things they dislike when working with others. Be sure your own interests are represented by adding anything that is missing. Compile the list and re-distribute for feedback. Do several iterations of this until the team reaches consensus.
• Make the ground rules visible and revisit them from time to time as things change.
• As the manager or leader, it is your job to enforce the ground rules both positively and negatively. The more lax you become in enforcement, the more lax your team will become in adherence. And remember to always praise publically (positive) and punish privately (negative).
• Most importantly, never ask or expect your people to do anything you’re not doing. You MUST walk the talk, lead by example.
  

Good teams don’t just happen, they’re made. And it’s your job to make them. Ground rules are the social contract that helps hold a team together. They tell us how to live together in community. Why we live together in community will be the subject of a future post.

While I'm at it, this week I attended a meeting of the Project Management Institute's NC chapter. The speaker was "SharePoint sensei" Dux Raymond Sy, one of my cool friends from the Washington DC area. It was good to catch up with Dux as well as a number of friends I hadn't seen for awhile--I spent the past three years on the road, and it's good to be home!

Search Engine Optimization An Extension of Your Marketing Efforts Part I

Having an on-line presence is a necessity for most companies today. Once you establish your presence, update your content and make the site valuable for your potential and existing customers, you may think your job is over. But is it?

Remember the adage: If a tree falls in the forest and there is no one there to hear it, does it make a sound? Same question can be asked about your Web presence. Just because you have a Web site doesn’t mean that people know about it – especially if you are relying on search engines like Yahoo and Google.

If your site doesn’t have a presence in popular search engines, then you may be losing out on a huge volume of business or an ideal opportunity to market and promote your products and services. This is where Search Engine Optimization comes in.

Simply put, Search Engine Optimization (SEO) helps you increase your Web site traffic by achieving a greater presence in search engines. While defining SEO is rather simple, achieving maximum SEO takes a little more work. However, while many people consider SEO to be complicated, in actuality SEO is nothing more than an extension of traditional marketing with the ultimate goal of increasing targeted traffic toward your site. That’s what ultimately boosts sales or sells a service. It also markets and creates brand visibility for your Web site.

SEO refers to the process of adhering to a variety of best practices during the development of a Web site. Ideally, Web sites are built with SEO in mind, but often the existing site must be optimized. The optimization process involves choosing the best practices wherever possible and understanding the consequences of selecting other interests over SEO.

The first and most important step in a strong SEO strategy is site based optimization. This incorporates various steps that prepare your Web site to be found in the search results of any given search engine. These website optimization processes will help search engines understand what your site is about, in addition to assisting search engines to understand which search terms are relevant to your product or service.

If your content and code do not properly help search engines to understand your company products and services, a given search engine will not be able to identify your site as relevant to a searcher's needs. Further, an improperly designed Web site, will cost more money in lost business and redesign costs, than one that is properly developed and designed from its conception.

Once you have optimized your site to be found, you have to promote your site through off-site SEO marketing. The Internet is called the World Wide Web (www) because of the nature of how sites link to one another. Web refers to sites linking to yours; World Wide means that sites throughout the world inter-link, creating and registering your Web site as a real live place to go and do business.

Off-site SEO marketing involves building your company Web site into the web network via sites linking back to you. Search engines follow the network of links and index, or re-index, Web site pages within their databases as they find them. Links to your Web site are how your site will continue to be found and indexed, and plays an important role in how your company site is ranked within the search engines' natural rankings.

The three critical steps of SEO will be explained in Part II.

But How Can I Better Manage My Offshore Project?

One of the frequently asked questions I get when teaching project management for Learning Tree is, “but how can I better manage my offshore project?” You’d think everybody is doing it! Yet CIO magazine reports that only 4% of us are doing it, and the number one reason cited for not doing it is this management challenge.

Proponents of offshoring tout a 70-80% cost reduction. But that’s only part of the story. How can you argue with paying $20 an hour over there vs. $60 here? Well, here’s the rest of the story, as Paul Harvey would say. They don’t tell you that it takes two to three people over there to do the job of one person here. Or that the total cost of management reduces that savings to about 10% and now you have to put on your thinking cap.

Let me be clear, I am NOT suggesting that offshore resources are in any way inferior to local resources. My friends in the offshoring business come with impeccable credentials. This is not a people problem--I've managed GREAT people from all over the world. This is a process problem.

I’ve been at Pogo Health for a mere month. All the development work is offshore, and I had every intention of making it work. But one of the reasons they hired me is that, like everybody else, they’re struggling to make it work. I’ve managed global and remote teams before, but nothing like this! And after a mere month, we’ve made the difficult decision to bring the work back home as quickly as possible.

I don’t know that this experience helps me better answer that question, “but how can I better manage my offshore project?” But I do have some fresh (raw) lessons learned under my belt. First, I highly recommend that you delegate the day-to-day management of your team in India or China or Vietnam or Timbuktu to somebody on your staff who is from there (for obvious reasons—cultural, language, etc.). Another reason I was hired was to reduce the total cost of managing our offshore team. Is anybody surprised that our offshoring relationship is deteriorating in direct correlation with our efforts to get a grip on the cost of managing it?

Second, be very very sure that your project is a good candidate for offshoring. Do not, I repeat, DO NOT attempt to offshore an iterative project. Yet another reason I was hired was because I’ve built my career on Agile principles and methodologies. The company rightly recognized that our business is agile (can you think of a business that is not agile these days?) so our practices better get Agile. But offshoring is pure Waterfall. (I expect negative responses but that's the point of this blog!) Waterfall and Agile go together like water and oil! One of my mantras is “execute or be executed”—the new (old?) business reality. Our offshore team is struggling to execute. Enough said.

While I’m at it, this week I attended a meeting of North Carolina Technology Association’s (NCTA) CIO Forum. It was a good discussion of collaboration trends and technologies led by Martin Marietta’s Chuck Musciano. At our place we’re using chat tools big-time for remote conversation, and I also host an IT blog that those outside IT love (and those inside IT tolerate). And we’ve found that a simple phone camera is a good way to digitally capture those whiteboard sessions. And rather than firing off that email that risks misunderstanding, how about emailing a quick audio or video recording instead? (Be sure to include keywords in the title for search purposes later.) A couple of tools I jotted down for exploration are Camtasia, CamStudio, and MediaWiki.

Of course there was also a lot of interest in SharePoint so, finally, I want to put in a plug for a friend of mine. Dux Raymond Sy, one of my cool friends, is a "SharePoint sensei" and he’s coming to RTP. Dux will be speaking at the May 15 meeting of the Project Management Institute's NC chapter. I’m double-booked that night but plan to stop by just to say hello. Be there or be square!