Which projects should you focus on first?

Continued from:

“Get Your Projects Under Control…”

http://businessanalysis56.blogspot.com/2009/05/get-your-projects-under-control.html

If you have too many projects going at the same time, pick the best ones to focus your resources on: but how do you do that?

If no other factors are in play, choose the projects that most closely look to be near completion. This can be difficult, given that “90% done” syndrome ; you may focus on a 90% done project and find it is more like only 10% done in reality(!), at which point I would drop it and move on to a more promising project.

Other factors can be applied in selecting projects sub-set; they depend a lot on how much information you have on your projects, and can include:

- Business Value or Return On Investment: if you already have some notion of the value of a delivering a project, especially a cost-benefit analysis, you can try attacking the projects with the highest value if that is something your business management will appreciate. Many companies are good at defining value or benefit up-front, but only the better companies take the time after a project is complete to confirm if the benefits really were realized. If you company does not do this yet, suggest they start, but avoid this factor for selecting the projects subset until they do start.

- Project Priority, which can be determined based on a combination of Business Value and/or other Project Drivers. This is often a weighted calculation where values are assigned based on how well a project addresses items such as ‘increased sales’, ‘improved decision-making’, ‘better customer service’, etc. . Each project has a priority value to compare to others, and highest-priority projects are initiated first.
If you have a Priority value assigned for your projects, but it really hasn’t been the key factor in initiating projects, then start using it; that’s pretty obvious, I know. What is more likely is that priority did play a part in initiating projects, but has not carried over to decisions made during projects. If your projects are now executing out-of-priority order, see if re-ordering them will help in faster delivery and increased business value.

- When all else fails, Ask. (Or just start with Ask). It will be no big secret if you have many projects underway with no ends in sight. It is also likely that many current stakeholders may not have been involved when some of the projects were started. So, you can meet with these stakeholders to determine what their current priorities are and which projects are of most value to them.
The usual issue with this approach is: who should I ask? In a perfect situation, I look for the person highest in the organization whose span of control covers all departments who sponsored or are impacted by the projects. However, this person could be senior enough in the company that they may decline to help you, preferring to delegate to their reports. Querying and meeting with this group may give you the priorities you need; or, it may illustrate any politics or power struggles that are on-going, for which you may be able to facilitate a resolution or at least a compromise…or not. In the latter case, it may be necessary to escalate this back to groups’ common manager for resolution.

So, one or more of the above factors may assist you in identifying the best sub-set of projects to first target for quick completion. If no strong values or priorities can be discerned, I would default to those that can finish the fastest.

Get your projects under control...

In these trying times…or some variation of that…is the first line in every other article or post of the past 6 months, and I am getting really tired of it.

What usually follows is advice to get things in order, whatever the thing of interest is, while focus is elsewhere and before it turns back to you. However, if your thing of is interest is the slate of current IT projects in your organization, there indeed may be some opportunity here. It’s time to get positive.

Do you have a lot of parallel projects? Probably figgting for the same more limited (than ever) resources? Are they all target-date challenged, i.e. all late or later than late? Now is the time to get them under control.

The absolute first priority is to wind-up as many of these projects as possible, as soon as possible. This sounds like common-sense; it is certainly sensible, but not at all common.

No rocket-science here, you need to allocate all your resources to a subset of the on-going projects, get some successful project deliveries, and then look around for new opportunities. If you have a large slate of current projects, you may need to do this again (and again) for another subset of projects. Keep doing this until the number of current projects no longer exceeds your capacity to resource them, or as close as you can get. Do your utmost to avoid initiating any new projects while cleaning up the current projects.

(Of course, some projects cannot be delayed, especially changes needed for new legislation or other compliance issues. Jump on those immediately and get them done quickly so you can get back to the other on-going projects.)

It also helps if you can manage to identify any existing projects that can be canceled out-right. This will not be totally in your control, as the business unit or sponsor that wants the project done may resist. It is just to your advantage to identify any projects that are clearly no longer needed, and who’s sunk costs should be capped.

How many projects should you focus on as described above? You can’t overload a single project either, without incurring diminishing returns. A rule-of-thumb would be to define the number of people on a typical project team in your shop, and then divide that number into the total number of people you have available for projects. There are many ideas and opinions about optimum team size, usually around 7 plus or minus 2.

Next time: which projects should you pick first?

IT Projects Success - Principle #13: Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables

13. Given many medium to small software Deliverables, use Architecture to manage and integrate the Deliverables into a complete system.

This is a more specific statement of Principle #3; in Cascade, an Information System Architecture is used to integrate the two week deliverables, until a complete deliverable (component, sub-system) is assembled.
In parallel, a release schedule is a great approach to support delivery. Gather the usable deliverables into timed releases that go into production together. As per Principle #11, a Release each quarter is recommended. The business receives what they are paying for often enough to be of value, but not often enough such that assimilation of change is so frequent it causes chaos.

IT Projects Success - Principle #12: Within the three month phase, parcel work into two-week periods.

12. Within the three month phase, parcel work into two-week periods; analyze for 2 weeks, then design and develop for 2 weeks (two developers), and then test for 2 weeks. When the first 2 weeks of analysis is done, start the next two weeks of analysis in parallel to the design/development; carry on in cascading 2 week periods until the entire project scope has been addressed.

OK, a 64 word-long paragraph is pushing the boundary of a ‘Principle’, but this point is the basic building block of Cascade. Are two week periods too aggressive? I think not, based on experience. I find developers and a tester like to work in such quick bursts, as delivering more results faster makes anyone feel more productive and accomplished, and illustrates quickly what works and doesn’t work. However, small bits delivered quickly need to be integrated into an overall solution, which leads to Principle #13.