Overheard in the tech blogosphere » Project management

Overheard talking about TechStat

Margaret Rouse — Fri, 09 Apr 2010 12:44:21 +0000

“Given the size and complexity of the multi-billion dollar Federal IT Portfolio, we must relentlessly focus on the health of IT investments across the government.”

Vivek Kundra, TechStat: Improving Government Performance

Vivek Kundra, the first federal chief information officer, is in charge of a network with 24,000 Web sites and 1,100 data centers. The US federal government is the largest single buyer of technology in the world at $71 billions dollars annually.

As the President said in his inaugural speech “those of us who manage the public’s dollars will be held to account, to spend wisely, reform bad habits, and do our business in the light of day, because only then can we restore the vital trust between a people and their government.” The IT Dashboard and TechStat Accountability Sessions are both critical tools in delivering better value and results for the American people.

[TechStat sessions enable the government to turnaround, halt or terminate IT investments that do not produce dividends for the American people. Investments are carefully analyzed with a focus on problem solving that leads to concrete action to improve performance.]

http://www.facebook.com/pages/Vivek-Kundra/56152836529?v=wall#!/pages/Vivek-Kundra/56152836529?ref=ts

Overheard – burn down chart

Margaret Rouse — Tue, 26 Jan 2010 17:07:02 +0000

As a pilot, I like to think of a burn down chart as being like the glide path of an airplane on final approach…If you are stabilized on the glide path you will hit the runway at the designated touchdown point. If you are too high, you will not make it to the runway…If you are too low, watch out for the trees!

Peter Stevens, Towards a better burn down chart

Today’s WhatIs.com Word of the Day is burn down chart.

Release management – the IT equivalent of herding cats

Margaret Rouse — Fri, 12 Jun 2009 16:28:27 +0000

Studies have shown us that a large majority of IT projects fail either in part or outright for non-technical reasons that could have been prevented with proper planning.

George Spafford, Release policies set standards for rollouts

Today’s WhatIs.com Word of the Day is release management.

As part of a webcast on Understanding the ITIL Trinity of Configuration Change and Release Management, George says that:

29% of projects deliver on-time with expected features
53% are challenged (are delivered on-time without expected features)
18% outright fail outright

It’s not surprising that George attributes these dismal numbers to non-technical factors, including lack of project planning, poor requirements definition, not getting the right stakeholders involved, poor communication and insufficient management oversight.

I’m frankly surprised that the number of projects that deliver on-time with expected features is so high. I would have guessed…3%.

Skunkworks – Make it so

Margaret Rouse — Tue, 09 Jun 2009 18:03:43 +0000

“Security consultants believe that the ongoing economic malaise is prompting many businesses to rush skunkworks server virtualization projects into production without thoroughly considering how these deployments might affect their overall security posture.”

Heather Clancy, Tech Watch: Security pros want strong policy for virtualization

Today’s WhatIs.com Word of the Day is skunkworks. A skunkworks is a small team that’s given magical powers (think “all the stuff they need”) to get a task done. The good thing about a skunkworks is that nobody tells them “you can’t do that” or “we’ve never done it like that before.” The bad thing about a skunkworks is that because they operate out there on their own, they may accidently break something that’s associated peripherally.

The term got its start at Lockheed.

Overheard: Agile project managers must be xenodochial

Margaret Rouse — Fri, 06 Jun 2008 13:19:18 +0000

Most agile coaches move around from team to team and need to fit in with different groups. Not only do they have to be approachable by different people, but they also have to ensure that what they say and how they act doesn’t work to exclude people.

Patrick Kua, The Agile Coach, from A to Z

Agile Development Glossary

Margaret Rouse — Sat, 12 Jan 2008 16:36:08 +0000

Here’s a handy glossary for business owners who want to learn how to speak Agile to their PMO.

Acceptance Test:

An acceptance test confirms that an story is complete by matching a user action scenario with a desired outcome. Acceptance testing is also called beta testing, application testing, and end user testing.

Agile Software Development:

Agile software development is a methodology for the creative process that anticipates the need for flexibility and applies a level of pragmatism into the delivery of the finished product. Agile software development (ASD) focuses on keeping code simple, testing often, and delivering functional bits of the application as soon as they’re ready.

Customer:

In agile software development, a customer is a person with an understanding of both the business needs and operational constraints for a project. The customer provides guidance during development on what priorities should be emphasized.

Domain Model:

A domain model describes the application domain responsible for creating a shared language between business and IT.

Iteration:

An iteration is a single development cycle, usually measured as one week or two weeks. An iteration may also be defined as the elapsed time between iteration planning sessions.

Planning Board:

A planning board is used to track the progress of an agile develoment project. After iteration planning, stories are written on cards and pinned up in priority order on a planning board located in the development area. Development progress is marked on story cards during the week and reviewed daily.

Planning Game:

A planning game is a meeting attended by both IT and business teams that is focused on choosing stories for a release or iteration. Story selection is based upon which estimates of which stories will provide the most business value given development estimates.

Release:

A release is a deployable software package that is culmination of several iterations of development. Releases can be made before the end of an iteration.

Release Plan:

A release plan is an evolving flowchart that describes which features will be delivered in upcoming releases. Each story in a release plan has a rough size estimate associated with it.

Spike:

A spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The output of a spike story is an estimate for the original story.

Stand-up:

A stand-up is a daily progress meeting, traditionally held within a development area. Business customers may attend for the purpose of gathering information. The term “standup” is derived from the way it is run all attendees must remain standing to keep it short and the team engaged.

Story:

A story is a particular business need assigned to the software development team. Stories must be broken down into small enough components that they may be delivered in a single development iteration.

Timebox:

A timebox is a defined period of time during which a task must be accomplished. Timeboxes are commonly used in agile software development to manage software development risk. Development teams are repeatedly tasked with producing a releasable improvement to software, timeboxed to a specific number of weeks.

Velocity:

Velocity is the budget of story units available for planning the next iteration of a development project. Velocity is based on measurements taken during previous iteration cycles. Velocity is calculated by adding the original estimates of the stories that were successfully
delivered in an iteration.

Wiki:

A wiki is a server program that allows users to collaborate in forming the
content of a Web site. With a wiki, any user can edit the site content, including other users’ contributions, using a regular Web browser.

Here’s our newest Word-2-Go glossary — it’s got a lot of our Agile vocabulary all in one handy printable page. Take a quiz and see how many you already know!.

Overheard: Who should the PMO report to?

Margaret Rouse — Tue, 08 Jan 2008 15:05:15 +0000

Where should the PMO exist and report to? Since most companies have a lot of projects located in the information technology (IT) area, this becomes a natural place to locate the PMO.

Bob Turek, Choosing the Right PMO Vision Series

The line that stuck in my head from Bob’s post was: Usually something painful drives the creation, or reevaluation, of a PMO.

Amen.