Archive for category project management

Gartner Highlights Key Predictions for IT Organizations and Users in 2010 and Beyond

Here are Gartner’s predictions for the coming years in IT:

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.

, ,

1 Comment

The Laws of Simplicity

In these prior blog posts:

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:

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.

, , , , ,

No Comments

Interview with Microsoft Project’s Seth Patton

Here is an interesting interview with a marketing director at Microsoft Project regarding their product roadmap and strategy.

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, 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.

No Comments

A Sincere Apology

In the fifteen years I have been with Tenrox I have seen two kinds of people managing businesses and running projects:

  • 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:
I hope more of our team members adopt this mindset.

No Comments

Scrum Project Management

Here is an amazingly good video that describes the Scrum development methodology in less than ten minutes. I highly recommend it to anyone who wants to get a quick and effective introduction to a new and now proven project management and software development methodology. We have started to use scrum in some of our R&D projects. We decided to use Agile/scrum to develop two new product modules that require a highly iterative creative approach. We continue to use traditional PMBOK type project management for feature enhancements and core product development. After some debate we concluded it is better to initially apply Scrum to “blue sky” type R&D projects. What we learn from these new projects can then be applied to our feature enhancement and core product development efforts. I will be able to share our experiences regarding these new methodologies in about six months when we are closer to the end of these pilot projects.

1 Comment

The 2009 Chaos Report – Is Project Success Really that Rare?

The Standish Group released its widely quoted report (available for purchase here) on project success in April 2009. The latest report is based on a survey of more than 300 organizations and 30 interviews. A summary of the findings is shown in the figure below.


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.


Unlocking the cloud

Here is an interesting perspective on cloud computing from the Economist. The article contends that customers subscribing to an on-demand service should be wary of data ownership and the data migration difficulties they will face when moving their data from one SaaS (software as a service) vendor to another. The author positions open source as a liberating technology and sees cloud computing as new attempt by software vendors to lock-in customers.

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 Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences

Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.

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.

1 Comment

A Primer on Just-in-Time Resourcing

A Primer on Just-in-Time ResourcingSM, Enabling the Concept of Just-in-Time Resourcing (JITR) with Project Workforce Management is a white paper I co-wrote with Randy Mysliviec CEO of RTM Consulting. Just-in-Time Resourcing  (JITR) can offer significant advantages and immediate benefits to professional services agencies, consulting companies and other expanding technology firms needing improved resource planning. “Stop gap” and other measures can compound the problems in handling large scale fluctuations in labor sourcing and management. Find out how JITR addresses the need for optimal resource supply for growing businesses, and how to enable JITR through project workforce management software.

You can register and download it here.

No Comments

Obama project management

Reporters and people alike have come to admire these distinct qualities in Obama: his generally calm and friendly demeanor, his message of respectful disagreement and yet cooperation, … trying to find common goals and rivals coming together to achieve these goals. Of course, all of this is quite a radical shift from the type of message we have seen from both sides of the political spectrum. So much of what Obama stands for (and hopefully will stand for throughout his presidency) can be applied to how we run our businesses, and projects.

Just like many of you, throughout my career, I have had my differences with some people. Whenever, I or any of my rivals chose to firmly disagree, argue, stand our ground or take a dogmatic position on an issue we all ended up losing somehow. This is specially true in any type of partnership. Hard ideological positions create nothing but obstruction, or worse destruction.

As an example, take the senator that single-handedly blocked the confirmation of Hillary Clinton on January 20th, knowing full well that she would be easily confirmed the next day whether he likes it or not. What is the point of obstructing and delaying what is an inevitable outcome? Instead, he could have simply stated his objections, understand that he has to work with this new team and get on with doing his job. Possibly spending some of that time and energy on the credit crisis instead. These are the politics of the future. As a friend of mine said, chances are when he runs for reelection he will be replaced by voters with someone who gets that this mindset change must occur.

So all of this got me thinking. How would Obama manage projects? I look forward to reading your thoughts on situations such as below and how you think an Obama type character would handle them.

- Dealing with a difficult customer: A customer that refuses to pay any invoices due because the project is late. The customer has changed project scope several times but does not think the scope changes are the root cause of the delays in achieving the milestones. He does not agree that the customer's team bares any responsibility whatsoever for the project's issues. The customer is absolutely convinced that his internal resources are doing a fine job and all the blame lies with your team.

Internal Politics: Your team and your projects are doing fine. So the "boss" and other project managers constantly raid your team for emergencies and try to take your resources away to fight fires. When you confront them they explain how urgent their issues are and how they absolutely have to "borrow" these resources. You know, of course, that it is only a matter of when not if that your projects will start to be yellow and red flagged as a result of these workforce planning (or lack there of)  issues.

How would an Obama-type leader handle these project management challenges?

, , ,

No Comments