Wal-Mart.

Whether you love them or hate them, there’s no denying their scale. The company is just huge. When they make a small change, it can have large-scale implications.

When Wal-Mart Changes A Light Bulb

Hal Macomber has a post up that cites an upcoming Fast Company article that covers Wal-Mart’s anticipated change to using coiled fluorescent bulbs instead of standard incandescent bulbs.

Its estimated that if Wal-Mart can successfully do so, that would be the equivalent of pulling 1.3 million cars off the road in terms of reducing carbon emissions.

Besides the environmental impact, the savings in energy costs to Wal-Mart (and therefore reduced energy demand in the economy) are really big.

Each fluorescent bulb uses less than 1/3 of the energy of a similar 60 watt incandescent bulb. When spread out over the entire network of Wal-Mart’s 3,000 plus stores, we’re talking millions and millions of dollars in cost savings and a huge reduction in wattage demand.

This is a great example of how a small change can have large benefits.

Often, companies try to improve operations or project performance through large, revolutionary sweeps. These are accompanied by the sounds of “new paradigms,” “rethinking everything” or “massive organizational change.” People can spend a long time rethinking their processes, defining requirements and risks for an anticipated change, all the while growing the scope of the project.

Soon, the scope is so big and complicated that it becomes impossible to fund, politically risky to support and near impossible to implement. At the end of the day, nothing gets done and management gets burned-out on the idea of process improvement or improved project management.

Companies can sometimes get more accomplished by taking tiny steps, changing little things that make a big difference.

In every company there are well-defined, discrete areas which can be changed. Champions of these well-defined projects can see them executed and delivered, from start to finish. They can measure the results and build a solid foundation for further improvement.

While the change may not impact energy demand on the planet, it can make a big difference in the performance of your company or process.

You can tell a lot about the target market for a project management software based on what they call planning.

a) If the tool doesn’t having planning, it’s a tool for helping keep things in order.

The target is probably smaller organizations, teams or individuals who may or may not interact with other people as part of the project. The main goal of this type of project management software is to help individuals be more organized or to give some structure to the way people interact.

b) If it has planning and the planning is a dry run of a schedule, the software is built for improving the way you get things done. The target market is departments or companies whose business is a series of projects involving teams.  The projects are often in areas like marketing, IT, web development, software projects or education.

Keep in mind, project management software will vary as to how you can see the impact of dry runs under different scenarios and how the dry runs compare to a baseline. But overall, if the software has a set of tools called planning and they are mostly about white boarding project schedules or potential resource allocations, the software is for improving ongoing operations involving teams.

c) If its has planning and the planning tools are about business goals and/or if the software has an abundance of what-if type tools and functions, then you are looking at a larger scale, cap. ex. type project management tool or project management software.

Planning of this type might include functionality which autogenerates schedule variations based on different constraints or variables.

This type of project management software is suited for large-scale portfolio management and decision management tools or projects involving design and/or building something new and very big (tens of millions of dollars and up) with large numbers of teams, departments or companies working together.

Project planning is often taken for granted by people in charge of projects (in an everyday, business sense) -or by their bosses. They overlook the need develop a deliberate and disciplined approach to spelling out tasks, personnel and resources on a project by project basis.

This may come from a mix-up in the way people talk about planning and project plans.

There are two different ways of looking at project plans and the act of planning.

One is the view of traditionally trained project managers. These are people that likely manage large capital projects like designing airplanes, nuclear reactors and satellites.

These type of projects are about breaking new ground in terms deliverables or design and production methods. Personnel on these projects may have never worked with each other before. There are a lot of unknowns and the project itself is an exercise in uncovering unknowns and solving problems.

Planning, in this cases, is a necessary pre-condition for the project (and certainly for scheduling). It is a matter of defining deliverables, forecasting and preparing for unknowns and identifying risks which can endanger the project. To use a phrase from a recent post on Herding Cats, planning is the creation of the condition for success of the project.

The second way of looking at project planning is developing a plan to get things done. This is probably the way most people think of planning. In this, more common definition, the project’s goals are defined by the business goals of the organization. Its what you want to get done.

Projects, in this case, are about improving ongoing activities, getting things done better (not breaking new ground). Project management, then, is about gaining clarity and control of ongoing tasks using people that have mostly worked together before.

Here, a project plan is a schedule, the plan to things done. To quote Herding Cats, it is the mechanical production of the sequence of work efforts needed to implement the plan.  Planning is the exercise of creating a schedule to get what needs to be done delivered.

Search engines may be stifling the success of software companies. How?  By assuming all searchers are the same.

In general, a software company writes for a target audience, its intended customer base. That audience may or may not be people who spend a lot of time on the internet or in the blogosphere. (For brevity, let’s call those who do spend a lot of time on the internet and blogosphere netizens.)

However, it seems that search engine rankings are determined, in large part, by the amount of presence a specific url has on the general internet and blogosphere. The more a particular software is talked about by netizens, on net-based outlets like blogs, websites and forums, the higher the likely ranking of that particular software on a search engine.

Due to their popularity, search engines are often the first place people turn-to when looking for new software. This is particularly true of non-netizens who don’t know the specialized websites or back corners of the internet where they can find insider information on software or technology.

So, the non-netizen goes to the search engine and searches for the type of software its looking for.  The results come back ranked by the amount of buzz by netizens.

The ranking may be a perfect set of choices for one particular user, say a netizen or those who are looking for the same thing netizens value. But the results might not be a good set of choices for the needs of the non-netizen.

The right software might be buried deep on some double digit page of the results.

The non-netizen may never find the right software. The software company misses out on the customer (and therefore the revenue). Both sides lose.

There is a potential paradox here. That those who most need the help of search engines to find the right product, are least likely to find the right fit in the search results.

There are two ways to manage a project: with brute force and with finesse.

Brute force managers are like rock climbers who uses their arms to pull themselves up a wall. It can get you there if you have the strength, but it sure is tiring and ugly.

Project managers who use finesse are like climbers who realize that their can legs do most of the vertical lifting. They just need to use their head to find the right placement. Climbing with their legs (which are stronger than arms), using their hands mostly for balance, they can climb a lot higher, for a lot longer and its much prettier to see.

Of course, there are just some walls, like there are projects, which need brute force moves to get to the top. The finesse climber knows how to execute those moves and will have more strength saved for them, particularly near the top.

Some people get to finesse over time and experience. At its core, though, it’s a philosophy that a person adopts. Its an outlook that a climber has when they approach a wall. They come to the rock calm, ready to meet it, to get the job done.

A brute force climber looks at a rock as a challenge to conquer, as something to beat and power through. The wall is against them. For training they lift weights and solve hard test problems so they can stomp on anything.

The same holds true for project managers.

Brute force managers spend time getting certified, reading books, solving theoretical problems. With papers in-hand, they power-through projects often with a disdainful attitude towards anyone not in the specialized project manager club.

Finesse project managers learn the same techniques. But they train by spending their time listening, analyzing projects and talking to people. They get to know their team. They also learn about themselves and how their insecurities and ego can get in the way of projects. They come to a project to meet the project goals, gracefully. They advance the organization and their project team.

Behind the buzzwords of Web 2.0 and web-based software, there is a specific approach to ease-of-use and friendliness. Its reflected in the way the software is designed and, in the best cases, in the company’s attitude towards users. This approach makes a compelling business case for web-based software.

These should resonate loudly with buyers of project management software. In this space, buyers face a crowded market. And a lot of people have been burned or turned-off by other types of project management software in the past.

These are cut-throat, quick-to-the-chase, cost/benefit type reasons. There are many other advantages to web-based project management software. But here is a short-list for the risk aware, business side of things.

1) Cheap to Try. The dollar cost of a pilot or test-drive can run anywhere from cheap to free for this kind of project management software. You don’t have to waste a lot of time with sales pitches or slide shows. You can try it and see if it fits.

2) Easy to Pilot. The tools are easy-to-use and generally can be learned quickly. You can do a live pilot without the pain and managerial pushing required with some older project management software.

3) Low Risk to Failure. You don’t have to put your career on the line to try it out. Since it doesn’t take a ton of money or time you don’t have to spend a lot political capital to try out this kind of project management software. If it doesn’t work, so be it, at least you tried to solve a problem.  If it does work, you’re a hero who solved a problem without betting the farm.

I have the pleasure of speaking to hundreds of people looking for project management software every month, and what I find amazing is the great difference in the way they are all working from one another. When I started speaking to people about their project management needs, I believed for the most part that everyone would basically be working in a very similar fashion. After all, we all put on our shoes basically the same way, brush our teeth, and walk upright as we move from place to place. But the more I spoke with potential customers, the more they kept asking me about very specific software functionalities. The first part of the question does your software do x and then y and then z, is followed by surprise when I answer that no, no one else has ever asked about that feature before. “Really?!” Is a classic response and they pause in disbelief.

Consider the surprising idea that most project management being done today is accomplished via MS Word and Excel. Many companies have developed elaborate processes around these tools, using them pretty much as tracking lists to keep track of projects. Unfortunately, using these products for project management is like using a Phillips screwdriver when you need a hex wrench. You are looking at a laborious and tedious process of arm wrenching sweat and toil. I have seen consistently profound time savings when people started to implement the right tool for project management and when I mentioned these right tools, I am not talking about a complex product like Primavera (which can be right for very complex jobs like the space shuttle).

In all the variety of approaches to managing project information I think the first step is admitting that the way you have been tracking projects in the past may not be the most efficient or logical. A lot of good minds have set about looking to make everyone’s life easier by creating tools to automate and make efficient the activity of project tracking. The other level of this admission is realizing that when you take on a new project tracking tool that you may be able to abandon the outdated manual processes of the past.

The great benefit to software is that it forces everyone do everything the same way. The obvious question then is does this PM software you are considering do it the right way? That really is the million dollar question in choosing a software product. Functionality lists are a great beginning to understanding what a particular piece of software can offer, but it is only a start. The real key is looking to see if the software does it the right way. It is not about what is in the software from a list standpoint, but rather, how does the software do that specific group of functions. Ultimately, will the tool do the job in the right fashion, and then will I be seeing tremendous increases in project efficiency and visibility.

Forget about manual labor and making more lists, that road is only a path to pain. An important first step when thinking about buying a new project management software tool is to consider keeping a very open mind, and understanding that you now have the opportunity to change the life of your company by accepting new approaches that in the end might just alter your group performance in a dramatic way. So toss out the old way, and test out the new way you can start to master your projects with ease.

Note: This is not a political entry, despite the subject of the article referenced below.

Daniel Henninger of the Wall Street Journal makes an interesting comparison between the general blogosphere and public demonstrations in the 1960’s. He likens similar-minded, link-sharing, bloggers, in his phrase, blogospheric daisy chain’s, to events or happenings in the 1960’s. They are part protest, part public display and as he says “part rock concert, part street theater, the rush of being part of a morally unblemished belief system.”

It’s a sense of belonging and being oneself voluntary and meaningful association with others or with a common cause.

The comparison sheds some light on the intangible feel of Web 2.0, web-based software. As an example, the technology behind blogs enables the creation of open spaces where people can rush in, join-up and participate, in a comfortable environment.

Web 2.0 type, web-based software, comes from the same place. It has an open, unrestricted feel to it a breather from MS Windows based desktop software or enterprise software that’s structured in the same way.

Its also a different breed from software motivated by ASP as business model or a Software As A Service (SAAS) model. (These tend to be about amortizing user-fees over time, rather than changing the user experience.)

Of course, web-based software has more rules, more defined parameters than blogs or My Space. The software needs to have more “shape” to it to convey functionality. But at its core, its firmly about things some would call “hippy-ish” like collaboration, networking, sharing and un-complicated association.

In practice, this means that interface, architecture and rules should intuitive and non-burdensome. When dealing with a group of users, information should gathered collaboratively and distributed out, shared across the relevant user network. Users shouldn’t have to spend days in training learning how to conform to someone else’s ideas of workflow or methodology. The software should let people be themselves and still belong to the project or cause and participate in its workflow.

BusinessWeek Online has an interesting article about failure. It cites a couple of high profile successes (like Bill Gates and Abraham Lincoln) that had failed businesses early in their careers. It then goes on to talk about making business failures more productive through analysis and review.

The same holds true in projects. A huge number of projects “fail” in that they don’t meet original expectations, timelines or budgets. Sometimes they even fail by not producing the expected deliverable. Good project management can help minimize these kind of failures. But even the best team or is not going to bat 1000.

A good, objective review can make turn failures into springboards to better performance. Take the time to get distance on a project and to bring in other eyes to look at what went wrong. Some project management software (like Vertabase Pro) have the ability to warehouse projects with all their data so they can be reviewed and learned from -like watching the video replay of a baseball game.

Failed projects also take a psychological toll on team members or project managers. They sometimes think that it was their fault that things didn’t go according to plan, that there was more they could’ve done. While there is always room for improvement, a negative, guilt-ridden mindset will sap energy out of teams and managers, lowering future performance (and morale).

Psychologically, a more positive way of dealing with failed projects is to define success in terms of individual performance, and not in terms of project deliverables or the project plan. Was I (or person x) moving the project forward or dragging it down? Even the most experienced people can have their deliverables blow-up through no fault of their own.

The most valuable people to have on a team are people who can roll with the punches and keep coming back to the plate. People or project managers who are easily dejected or who only perform when things are going their way are dangerous to the long-term stability of a department or team.

Use failure as an opportunity to coach team members on mental strength and endurance. Use failures to foster a productive atmosphere, to show people the bigger picture of what they do. And if there are people who can’t be coached, use failure as a chance to cut them from team. Sometimes people can learn more from a real sense of failure, then from success. It worked well for the people mentioned in the Business Week article -Bill Gates seemed to turn out ok.

Scott Berkun has an interesting survey on his blog. He is researching innovation for a new book. I found his survery thought provoking . Hope he doesn’t mind me springboarding off it (for those interested in the original, check it out here.

To me, innovation is about solving a problem when existing solutions don’t cut it anymore. Underpinning this definition is a belief that there are very few “new” problems (if any), just obsolete solutions. Technical accomplishments and new research are like getting pieces of a puzzle to fit together how we want them to. We didn’t build the puzzle (nobody asked us how the laws of nature should work) but are trying to get new shapes or designs from it.

What drives innovation? Or, in other words, why wouldn’t an existing solution cut it anymore? I think dissatisfaction is at the core of innovation. Somebody or a group of people, isn’t happy with the ways things work. So they try to figure out another way to make things work. The exact way they solve the problem itself isn’t necessarily the innovation. The solution could be made up of existing methods, processes or technologies. But the innovation is in the application of those methods, the fact that it solves a problem and takes away the dissatisfaction.

There is a ton of confusion in the project management software market. A simple search on the term turns up hundreds of software packages. They range from high-end, super engineering type products which can be used to build bridges to simpler products which can make life easier for a two person design studio. How come there is so much confusion? How can someone get a handle on the type of product they need?

Part of the confusion stems from the definition of a project in itself. The Project Management Institute defines a project as “a temporary endeavor undertaken to create a unique project, service, or result.” This mean it has a clear start and end-date and will deliver a product or service different from other products or services already offered. It means that the activities involved and the deliverables are unique and non-recurring. According to this definition, the more standard that tasks and deliverables become, the more the project becomes “operations.”

Operations, though, is exactly what most people are trying to improve on. Making something absolutely unique is a great undertaking, the realm of patents, engineers, R&D and product development. But most companies provide a product or service which already exists. While their product or service may be differentiated from competitors’ products, it is rarely something total unique. Where these companies make money is on being better than the competition at providing the product or service.

So, when looking for project management software, make sure you know what kind of “projects” you are looking to manage. Are they projects that conform to the official Project Management Institute type definition or are they more operations, type projects?

If you are looking to manage larger, one-off undertakings, projects that approach the official definition, you should look at higher-end, traditional engineer project management packages.

If you want to improve operations, make your company more efficient, your teams more effective and your people, including managers, happier, you should look at easier-to-use, next generation web-based project management software (like ours, Vertabase Pro).

While the types of projects this kind of software does a great job managing may not conform to the official Project Management Institute definition of a project, this seems to be what most people mean when they talk about project management.

I’ve found that a lot innovation floating around is cool, but doesn’t necessarily solve any problems or help make people’s worklife easier. This is nothing new. Useless innovation has been around forever. But it seems that the pace has picked up on software being released that doesn’t bring anything new to the table.

Wonder if it has anything to do with more developers spending time on blogs, reading the latest success stories or latest technologies and trying to hop on the wave –without understanding the fundamental problems being solved or the thinking that goes on behind the design of the functionality?

How has software already changed now that so many developers get input directly from the blogosphere? Is it creating software that solves problems better? Or, does it just increase the tempation to create something that rides latest, greatest tech buzz?