Six Rules for Great IT Project Success..

Hello!!

Friends

I want to share this article which talks about the rules which would help to achieve success in IT project
Project delivery makes IT organisations credible. When IT "gets it right" at the project level, its ability to impact the financial results of a company increases and its leadership in providing strategic direction improves. Good project delivery is the key to unlocking the door from the back-office to the boardroom.

Now, despite the need for companies in the 21st century to innovatively embrace technology to compete, CIO's still find themselves hearing second-hand about their company's strategy while line-of-business executives embrace the "IT as a commodity" philosophy.

For IT to contribute to a company's bottom-line, IT executive teams need to ensure project alignment with business strategy. Projects, and particularly large-scale programmes of multiple projects, need to be run flexibly, with an eye toward the larger business picture.

The following article present six straightforward principles - culled from our experience with Fortune 100 companies, ten person firms, mid-sized businesses and not-for-profit organisations - to turn your project into a bottom-line success.


One: Use Occam's Razor

Big projects are seductive. They are also inherently risky, costly, complicated and come laden with poor track records.

William of Occam, a 14th century logician, wrote "Entities should not be multiplied unnecessarily." Albert Einstein restated this as "Everything should be made as simple as possible, but no simpler." Apply their advice. Break up large projects into simpler, smaller projects or phases. Delineate each phase by its ability to provide an immediate and direct business benefit.

This approach has five benefits:

   1. Requirements are simplified. With tighter constraints, requirements gathering quickly centres on the most crucial. Time-box the remainder as "nice-to-have." Done well, requirements will be easier to understand, have clear connections between them, and should be easier to complete.
   2. A crystal clear focus is easily achieved when working on smaller, simpler phases.
   3. A succession of success can be built by rapidly delivering smaller project phases for people to easily see what they are getting for their money, time and effort.
   4. Smaller phases are simpler to manage, perform quality and compliance checks on, fix, tweak or debug, and modify as environmental factors demand.
   5. Phased projects are more easily paused (or halted altogether) as business conditions change. Personnel can then quickly pick up other activities.


Two: Buffer Consistently

Critical Chain Project methodology suggests minimum 20% buffers in your project schedule. Many Finance organisations expect a 10-15% cost buffer over initial estimates on major projects. And in his book Slack (2001), Tom DeMarco points out that to be their most effective, people need approximately 20% slack or downtime during their workday.

Ironically, many project managers set up a 20% buffer in their schedules and a 10% fudge factor in their budgets yet leave their people a 0% buffer. Thus, before scope "creep" or other project changes or problems, the chances for success have been cut by one-third.

Tackle this head-on with third grade math: prior to establishing a budget or plan, assume a 6-hour workday (20% buffer) at 15 project-focused workdays a month (after factoring in vacation, illness, holidays, company meetings, etc.); in other words, 90 hours of project work a month per team member.

Three: Prioritise the Soft-Side

Because projects are run for and by people, the primary role of the project leader is managing the "soft" people issues. The mistake most IT organisations make is to use the project leader to manage schedules, track metrics, control costs, assign resources, handling reporting and so forth. Instead, our experience has shown that successful project leaders focus first on five tasks:

   1. Run "interference" for the project team(s). Projects can quickly become politically complicated. By minimising the impact of politics on the project team members, the project leader reduces the risk of delay and scope "creep."
   2. Determine the right people to be involved, from project team members to pilot users.
   3. Make the final decisions on internal project issues. When money, time and resources are constrained, management by committee is not conducive to tactical success.
   4. Focus on specific goal-oriented completion of the project. Projects become imbued with changes, vague expectations, egos, etc. by project members, customers and project sponsors. The project leader must continually ask, "why." Press for specific answers on how the change, the additional goal, etc. get the project closer to completion. Ultimately, the business needs the project completed to reap the benefits.
   5. Perform quality checks at a regular interval on the schedule, the budget and the expectations of everyone involved. These are not detailed-oriented checks, but rather 10,000-foot reviews. Pick 3 random items and delve more deeply by probing with five or more questions each.

Four: Communicate to Ensure Accountability

According to Labformatics, one of the top reasons that IT projects fail is lack of responsibility over the project by both project teams and the customers. Take a page from the nonprofit marketplace and utilise three communication tricks to continually draw in end-users and sponsors.

First, build a simple, no frills website focused solely on the project itself. The site should contain the following:

    * Project goal(s)
    * Personnel involved
    * Timeframes (and current status)
    * Costs and allocations (i.e. "coding of purchasing interface")
    * Meeting minutes
    * Requirements documents
    * Project team checklists

You can also post the original business case as well.

Second, regularly distribute a short e-mailed newsletter with quick 8-12 word updates and links to the project website for more information. At minimum, the project update must address two ever-present questions:

    * "When are we getting the business benefits from this project?"
    * "How much is it costing us?"

Consider using the "5-15" rule: the update should take you no longer than 15 minutes to write and take the reader no more than 5 minutes to read.

Third, set up an unstructured blog environment for the project team members. This is critical if your project is being worked on by virtual or remote project teams, or is in 24-hour shift mode. The goal of the team blog is simple: keep everyone informed.

Five: Apply the Pareto Principle

In the 1800's, Vilfredo Pareto discovered that a small portion of any activity produces a majority of the results. Now called the 80/20 Rule or the Pareto Principle, its application in the IT world is essential to project success. The Pareto Principle is intuitively being applied when you hear the phrase "good enough."

In essence, if approximately one-fifth of the project will produce about four-fifths of the benefits, then identifying the essential one-fifth of the project will allow you to quadruple your results.

There are two techniques to determine which efforts produce 80% of your results:

   1. Ask your customers and your team, "what of our efforts are producing most of the results for you?" Be ruthless; eliminate or postpone every trivial task that does not directly contribute to the delivery of the business benefits of the project.
   2. Post the project goals in your office, in presentations, on your project website, etc., and turn attention to them at every question or change. Ask, "how will this improve our delivery of the benefits of this project?"

Six: Use Two Linear Betas

All good IT projects have a beta phase. The mistake many project managers make is to set up a group of users or IT personnel as a beta rollout group without keeping in mind the ultimate project goals. To improve your results, set up two sequential beta rollouts.

Beta 1 is strictly for IT personnel who support the various departments that will be using the system (for instance, IT department liaisons). They will provide your project team with a mix of real-world testing and tweaking while gaining valuable experience and comfort with the new system.

After the project team has had a chance to address the issues from Beta 1, set up the Beta 2 group: users from each of those departments. Preferably, select two users from each department, one who has and one who has not historically been friendly to IT projects. The latter represents the one-fifth of users that provide you four-fifths of your results.

So by following these Six Rules Do you really  think that your project will complete successfully which result in more credibility for your business ?