RIGHT Blogs                                                              

All Vendors Lie!

This was a bullet point in a presentation I was looking through the other day.   Since I work for a consulting company these days, the hairs on the back of my neck immediately stood straight up.  And then I thought about it a little bit, and I realized that the reason that I like working for Alliance so much is that we really don't consider ourselves a vendor to our clients.  We consider ourselves their partner.   That sounds like a pat comment, and one that every vendor would say, but it really is true.

The case for building a prototype

When we start a new software development project with a client, we like to recommend building a prototype as part of the requirements effort.  Especially if the project is to develop a brand new product or to do a major rewrite of an existing product.  But my experience has been that the prototype actually has benefits far past the requirements stage.   There are actually 3 key benefits that can be realized from building the prototype:

Software development: a “recipe” for success

I read recently that custom software development is similar to a master chef creating a new recipe.  No one expects the chef to create a perfect new dish on his first attempt.  Instead, the chef frames an idea of how he wants the dish to turn out and then he experiments with ingredients until he finds the right combination to bring out the flavor he was looking for.  Similarly, in Agile development or even a hybrid Agile like Alliance practices, the process of creating a new software product is iterative.  Each iteration adds new features in an attempt to find the right mix for a releas

Why aren’t you measuring your ROI?

As I noted in one of my previous posts, ROI (Return on Investment) is a potential measure of project success, but it is one that is rarely used.  On the surface that seems odd because almost every company requires some definition of the ROI for a project before approving it.  Some companies are very rigorous in their process, requiring formal business cases, and insisting on a 1 year or less payback on their investment.  So why is it that, once the project is over, very few companies seem to go back and check on whether or not they received the ROI that they were expecting?

The SACWIS Example: Can you predict how well a project will do?

Jim Johnson, chairman of the Standish Group, gave a talk at the XP (eXtreme Programming) 2002 conference where he gave an example of two projects that on the surface seemed very similar and which had very different outcomes.The two projects in this case were an implementation of the Statewide Automated Child Welfare Information System (SACWIS), one for the state of Florida, the other for the state of Minnesota.Florida’s implementation started in 1990 with a budget of $32 million and a planned completion date of 1998.Minnesota’s implementation started in 1999 with a budget of $1.1 millio

How do you define Project Success?

There are a number of surveys available that will give you statistics on how many application development projects succeed or fail, including the most famous of the IT surveys or at least the most quoted, the Chaos Report which is put out annually by the Standish Group.  If you look at their survey results, you might decide that the people who are running these projects have no idea what they are doing.  After all the 2009 report showed that only 32% of projects were successful, 44% were challenged, and 24% were considered failures.  And while those numbers are a definite improvement from when the Standish Group started conducting its survey in 1994, they paint a dismal picture of IT’s ability to manage projects.

How do you share information in your program?

When you are running a program, there is typically a lot of paperwork involved.  Project plans, dashboards, risk sheets, resource sheets, requirements documents, design documents, test plans, budgets, etc...  And there will be multiple revisions of each for each component of your program.   The amount of paperwork involved would probably kill a small forest, if you attempted to print it all out.   And keeping track of the latest versions of this information can be a nightmare for even the most diligent program manager, let alone the people working in the individual components. 

Monitoring Your Program Health (an overview)

Monitoring the health of your program is critical to the ultimate success of the program as well as to managing the expectations of your business users and the steering committee.   But program monitoring actually starts with monitoring the individual components / projects within the program and then rolling it up to the program level.   I'll list them here and in subsequent articles, I'll put more details on each as well as potentially some examples.

Request for Issues / Concerns

Since part of the reason for this blog is to help our clients and prospective clients deal with some of the common, and not so common issues related to Program Management, I'm inviting you to send us your own program issues, questions and concerns, and I'll incorporate them into future blog posts.   It can be a macro issue that affects the program as a whole (such as software quality assurance), or a detail issue that only impacts one component.  Just comment on this blog post or email me directly, and I'll address it.  Don't wor

Program Management: Building Trust (with Project Teams)

While it is important for project managers and program managers to have trust and rapport, it is also important for the Program Manager to obtain the trust of the actual project teams.  In the end, as much as we try to avoid it, keeping a program on schedule often requires some level of heroics on the part of the project teams to deliver.  But these are the people who are the least likely to have any direct contact with the senior sponsors of the program, which means that they need a connection with you as the Program Manager to inspire them to work hard towards the vision of the program