Are You a “Good” Stakeholder?

ran across an interesting blog post this week from Chris Woodill on how to be an effective stakeholder.  This post intrigued me because it examined the project team/stakeholder relations dynamic from the stakeholder angle rather than the putting all of the onus on the project team.  I have summarized some of Chris’ vision of the expected stakeholder roles and his counsel to stakeholders on “how not to drop the ball”.

“Good” stakeholders need to:

  • Make decisions – making decisions is the stakeholder’s primary responsibility
  • Approve documents – timely approvals of decisions and documents
  • Offer opinion and feedback -provide actionable feedback that can be translated into actions, revisions or improvements
  • Solicit feedback – help explain, sell concepts and capture feedback from the broader community
  • Support the team externally – evangelize the project, boost team confidence and help get organizational buy-in
  • Maintain a high bar of expectations – demand excellence from the team

In addition, “good” stakeholders should:

  • Be prepared for all meetings – take the time to do your homework before all meetings
  • Make decisions and offer feedback in a timely manner – don’t delay the project by being late
  • Be nice to the team – don’t bully the team
  • Articulate requirements clearly – if you are the domain expert, you need to provide clear and complete requirements to the team
  • Embed themselves into the team as much as possible – refrain from making us and them distinctions

Being a “good” stakeholder can make a massive difference in the success of a project and minimize project risk at the same time.

If you’re on a project team, you may want to forward this to your stakeholder.  If you’re a stakeholder, you may want to look in a mirror and ask yourself “am I a good stakeholder?”.


Five Myths of RIA

Laurie Gray from OneSpring (an iRise Strategic Partner) shared her thoughts on Rich Internet Applications or RIA during the monthly Catalyze webcast yesterday.

She started out with the RIA “elevator pitch” from Tony MacDonell who writes the InsideRIA blog:

Rich Internet Applications are software programs that are designed to run above the level of the operating system, and are universally available to you, where ever you may be when you need to use them. You can run them on any computer, in any context. Run them in the web browser, on the desktop, or even on mobile devices as well. Rich Internet Applications offer powerful user interfaces, that allow you to work or play in ways that are familiar, intuitive, and exciting. They leverage the best of the web, without sacrificing the power of the desktop.”

She also shared the origins of the term Ajax (Asynchronous JavaScript and XML) which first appeared in an essay by Jesse James Garrett from adaptive path in February 2005.

According to Laurie, the five myths of RIA are:

  1. RIAs provide the perfect vehicle for splashy sites
    • they are also amazing tools for complex, transactional, data-driven sites too
  2. RIAs bring people-centered design to information workspaces
    • most users will not care how the app was built, but if they have a bad experience, they won’t come back
  3. If you’ve designed websites, you can design RIAs
    • that’s not necessarily true
  4. It’s just like our software, of course our users will understand it
    • think again — there are lots of ways to do things
  5. RIAs provide a better user experience than traditional HTML
    • it depends — and sometimes it can be a worse experience

Laurie wrapped up with a demo of her favorite RIA websites and a list of valuable resources before answering a spirited round of questions.

The presentation slides embedded below and webcast recording are available from the Catalyze Community. Some of the questions from the webcast are also answered in Laurie’s Catalyze blog:

Radically Simple IT

In the March 2008 issue of the Harvard Business Review, David Upton and Bradley Staats from the Harvard Business School wrote an article about a radically new approach to developing IT systems called the path-based approach. As the authors state in the opening sentence, “enterprise IT projects continue to be a headache for business leaders.”

The article is a case study of Japan’s Shinsei Bank IT department and how they revolutionized retail banking in Japan.  Masamoto Yashiro, the former chairman of Citibank Japan, was brought in as the new CEO in 2000 and he hired Jay Dvivedi, who used to run IT operations for Citibank Japan as his Chief Information Officer.  Together, they led the development of a new enterprise IT system using the path-based method of application development. They call it the path-based approach because it focuses on providing a path for the system to be developed instead of attempting to define all of the specifications or requirements for a system before the project is launched. Shinsei succeeded in developing and deploying an entirely new enterprise system in one year at a cost of $55 million.

Traditionally, there are two choices for building a major enterprise system – the “big bang” approach of replacing the current system and processes all at once or the incremental method of improving the existing system one piece at a time.  Shinsei did not want the risk of the “big bang” method and did not have the time to implement the incremental method, so they chose a third method called the path-based method.  Some of the principles of the path-based method are variations on old themes while others are totally unconventional.

Here are some things they learned:

Don’t just align business and IT strategies – forge them together — Besides having the CIO report to the CEO, Shinsei business managers spend significant amounts of time in learning about IT.  In addition, they focus on understanding “foreseeable business objectives” and the interaction between business and IT groups is iterative and continuous.

Strive for extreme simplicity — Shinsei succeeded by employing the simplest possible technologies.  There were three keys to their simpler approach, limit the number of standards, create simple re-usable solutions and apply modularity to clearly specify user interfaces.

Give (some) power to the people — Many project failures stem from organized resistance to new systems.  When Shinsei rolls out a new system, they start by offering an interface that is similar to the old system – and only after users are comfortable with a new system do they turn off the old screens.  Shinsei also created a system for including feedback and requests from employees, customers, business users and technical users.  Comments have averaged about 100 requests per day which helps Shinsei continually improve systems and processes.

The conclusion is that “businesses must focus on building IT systems that cannot fail to improve…and adopting the path-based approach will provide flexible systems that can change as the business demands and can shift IT from being a simple platform for existing operations to a launchpad for new functions and brand new businesses.”

Imagine what would happen if you marry path-based method of application development with the visualization capabilities of iRise?

The complete article is a worthwhile read and is currently available for free from the Harvard Business Review website.

A Tribute to Joseph Juran and the 80-20 Rule

Joseph Juran, the management guru who coined the 80-20 rule or Pareto Principle, passed away last week at the age of 103.

I’ve referred to the 80-20 rule countless times in my career and I imagine I’m in the same boat with the majority of you who do not know the origins or author of the rule.

Juran named his principle after Vilfredo Pareto, an Italian economist in the late 19th and early 20th centuries, who wrote about unequal distribution of wealth.  Juran took these theories and extended them to describe “the phenomenom that in any population which contributes to a common effect, a relative few of the contributors account for the bulk of the effect.”  In simpler terms, he also referred to this as the “vital few” versus the “trivial many” or that 80% of the consequences stem from 20% of the causes.

Juran originally applied the Pareto Principle to quality management issues in manufacturing.  His work ultimately contributed to the development of Six Sigma, TQM and lean manufacturing.  In 1954, Juran was invited to Japan to introduce quality control concepts to their fledgling manufacturing industry – which led to many Japanese companies to become global leaders in their industries.

Peter Drucker, the late author and management consultant, said this about Joe Juran, “whatever advances American manufacturing has made in the last 30 to 40 years, we owe to Joe Juran and to his untiring, steady, patient, self-effacing work.”

Juran wrote his autobiography, “Architect of Quality“, in 2003.  His full obituary is available from the Minneapolis Star Tribune or the New York Times.