- We are still recovering from the recession; we cannot invest
- We only want to do the basics; we cannot afford to do more
- Our management team is cutting all costs; everything non-essential has to go
…

On the other hand, with companies on the rise you hear words like:

- We want to substantially increase productivity, we are ready to make the investment, what does it take?
- The basics are not enough. We want to do more. We want the most advanced tools so we can compete more effectively
- We want to leverage our existing investments but our management team is looking to invest in game changers
- What are some best practices you recommend?

Companies that take risks, make investments in good or bad times and stick with them all the way, and empower their employees to think about, find and implement game changers win. Those who start “restructuring”, “right-sizing”, “focusing on essentials only” “leave projects unfinished” don’t do very well.

Hundreds of prospects and customers later. The pattern is undeniable.

Would you characterize your employees by gender, age, race, religion, or in any other way when it comes to managing them and enabling them to be successful at their jobs? Of course not. And I’m not talking about verbally or publicly. I’m talking about when you sit down to do their review, determine their raise, have a one-on-one, or interview them, would you take any of that stuff into account? Again, of course not.

You know why? Because there are at least a dozen more important and relevant factors, like job performance, experience, knowledge, team work, etc. The only profiling I’m aware of in the real business world has to do with multinational companies managing workforces in other countries where employment law, compensation, and culture are different. To me, that makes sense.

But profiling groups by generation is ridiculous, no matter what the management researchers and gurus say. Not to mention that it’s dehumanizing.

I somewhat agree with Steve Tobak’s observations in that some of this generation talk is overblown and its importance exaggerated. However, from our own experience at Tenrox younger generations have very different expectations. When it comes to recognition, rewards, raises and bonuses, of course you look at job performance, experience, knowledge and other such factors to determine what is appropriate. But everyone does not feel appreciated or get motivated the same way. For some, an equivalent valued gift, a few extra days off, a paid vacation works better than a cash bonus or a raise. We try to take such things into account when communicating with or rewarding our team members; and yes, the employee’s generation plays an important role in how we approach such discussions.

http://www.gartner.com/it/page.jsp?id=1278413

The most interesting one is “By 2012, 20 percent of businesses will own no IT assets”. The argument they make is that essentially more and more organizations will use cloud computing and refrain from buying their own equipment. Also, more and more users will access corporate data using personal mobile communications and their own laptops. In other words the company will own and control less hardware; the equipment will all be owned and managed by third parties.

This is a surprising and rather aggressive prediction. I agree with the trend and I can see a future in which IT departments focus a lot more on strategic initiatives rather than managing now commoditized IT equipment and infrastructure. Cloud computing is radically transforming the IT function and will have a major unquestionable impact on IT budgets and how IT is perceived within the organization. But 2012 is awfully close. I do not think the transformation will occur so quickly.

Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences

Occam’s Principle Applied to IT Investments

I outlined how Occam’s Razor principle could apply to product design and IT investments. I recently stumbled on to the writings of John Maeda who has authored a book on the laws of simplicity. A summary of the laws can be found here:

http://lawsofsimplicity.com/category/keys?order=ASC

A review of the laws is a good refresher for anyone in charge of project management, new product development and software design. The last law states: Simplicity is about subtracting the obvious, and adding the meaningful. This is actually Occam’s principle which I described and provided some examples for in the above mentioned posts. In fact as John Maeda mentions in his book and on his website Occam’s principle is really an encapsulation of the first nine laws.

http://www.enterpriseirregulars.com/500/interview-with-microsoft%E2%80%99s-seth-patton/

I guess Seth has not kept up to date with technology trends all that much. If Microsoft’s strategy is to try and drive out independent software vendors (ISV) they are not going to do all that well with their customers or partners. With Software as a Service and cloud computing, best of breed is a clear hands down winner in this market. Just look at the huge success stories of salesforce.com, RightNow, Taleo, and Success Factors all of which are SaaS offerings; there are so many more SaaS and cloud winners out there. I think Microsoft is better off focusing on strengthening its ISV partnership base instead of alienating them with this kind of thinking and interviews. This is not forward thinking.

Here is another interesting exchange in the interview:

While PPM products, Microsoft’s included, contain many of the functions needed by professional services firms, they are still some key functions not available within Project just yet. These include: client billing; dedicated time entry for vendor, client, contractors, etc.; two-way interfaces with payroll systems; proposal tools; and, more. Nonetheless, Seth reminded me that thousands of Microsoft partners are service firms as well as users of Project in client work.

This sounds a lot like the old we have it all ERP type of talk. Well then I guess customers should wait another 10 years for Microsoft to develop these and other capabilities. Or customize the heck out of Microsoft Project to fulfill the gaps they perceive in the solution and to get what they need like these other companies he mentions have.

I still remember the first time I read a brochure from one of these large vendors. The brochure said they do everything under the sun. I got the same impression with virtually every release of Microsoft Project. To this day, all of these products have only fallen behind more, become more bloated, more complicated, and more out of touch with what customers really need.

• Type 1: A person who apologizes for his or her own mistakes and accepts the mistakes of others
• Type 0: One who never says sorry, denies everything

Like most companies we have both types of people at Tenrox. Thankfully we have more type ones than zeros. Recently, there has been a huge surge in customer activity and we need everyone at Tenrox to be at the top of their game these days to try and serve every single one of our users.

A few days ago I had to talk to a type 0 project manager regarding some of the issues we have with his performance, the projects he manages, his overall approach to the challenges we have, and how important he is given the current resource crunch.

As usual, his automatic patterns kicked in. I got the “It is just your impression”, “but you don’t understand”, “no this is not true”, “you are wrong” … types of responses. This is a hard working person with good intentions and reasonable abilities. Unfortunately, his inability to take responsibility for any mistakes, wholeheartedly apologize for them, and his constant slippery denials virtually guarantee that he will always be nothing more than a second rate mediocre consultant or project manager, at best.

I sometimes call myself the Chief Mistake Officer at Tenrox followed by a list of my personal and professional mistakes just in the last twelve months to try and convey how important it is for everyone to take chances, innovate and get out of their comfort zone … but none of that is any good if we don’t have the capacity to sincerely apologize and to accept our mistakes.

Here is a very nice article on the power of apology: http://ccr.byu.edu/content/power-apology.
I hope more of our team members adopt this mindset.

The news is not very positive. According to this report the number of IT projects that failed has actually increased since 2006, successful projects are also alarmingly harder to find. Here is a far smaller and less official survey on software project success rates.

From our own experience and all the anecdotal evidence I have gathered projects are often late and over budget but they are mostly successful. In my opinion the Standish Group’s survey is overly pessimistic on the success rate of IT projects. I find nothing on the Internet that explains Standish Group’s survey approach or confirms these findings. It would be better if they provided more details as to how they assess project success and how they can backup their claim of a negative trend in worldwide IT project performance.

The report did not highlight any new reasons for the higher project failure rates. There are many more capable and highly qualified project managers today than in 2006, there are better tools, an abundance of easily accessible information on project management lifecycles and methodologies, and better collaboration between all project contributors/stakeholders. I simply cannot see how the end results can be this bad.

This is the first time I ever heard anyone argue against cloud computing. To tout on-premise open source systems as liberating technologies and to call SaaS and cloud computing as a step back is simply out of touch with what is occurring in the marketplace. At the heart of its argument against cloud computing is the lack of standards for moving data from one service provider to another. However, the same can be said for migrating data from one on-premise solution to another, whether open-source or not. For example, have you ever tried moving data from an Oracle application into a Microsoft or SAP application? No common standards exist today that would automate the migration of any form of enterprise data from one solution provider to another.

However, the process of importing data has become a relatively painless, inexpensive and a low risk activity for most forms of data. Data in most modern enterprise applications (on-premise or on-demand) is represented in XML or can easily be exported to XML, now a ubiquitous standard for data representation and data exchange. Using XML, just about every cloud service provider (and even legacy application providers) have the tools and the expertise to migrate data from the customer’s current formats and systems. There may of course be some minor challenges to overcome and the migration may require investment in a few days of consulting services but I do not at all see how data migration results in vendor lock-in.

One thing that customers need to make sure of is data ownership. Tenrox project management software and workforce management customers own their data, whether they are on-demand or on-premise. This assures our customers that they are totally free to move to another service provider.

Cloud computing has tremendous benefits for the customer. The service provider takes care of all the details of software maintenance, bug fixing, data backups, 24/7 availability, 99.9% up time, data security audits and certifications, bandwidth, worldwide access, and much more. This frees internal IT to spend time on more strategic work such as IT project portfolio and resource optimizations, data analysis, portal/report development, and activities that are directly related to the company’s core business.

Applying Occam’s rule to product design and development could go something like this:

1. Design features that are simple to use
2. Provide just one way of performing a function
3. Don’t oversimplify

1) Design features that are simple to use

If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:

• There is a tendency to try and build an all in one comprehensive solution

  Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie. 

• Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage
  

  I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.

• Iterative reviews focused on what is missing complicate product design

  After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.

2) Provide just one way of performing a function

As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.

3) Don’t oversimplify

This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications.  We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.

However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.

In a future blog, I will apply Occam’s Razor principle to making IT investments.