Types of Projects

This is an attempt to classify different types of IT projects that happen on the Street.

1) Projects that are demanded by stakeholders: perhaps to support a new business or for regulatory/auditing purposes, etc).

Basically the business is hot for these projects. They demand them to be highest priority. These projects are necessarily agile and driven by stakeholders. Delivery is so tight and fast that stakeholders may even go straight to developers to discuss their needs. A BA may or may not be involved.

The pros:

• Gives the users exactly what they want, no more and no less
• Business feels IT is responsive to their needs

The cons:

• Business babble <-> Techno babble translation process (without a BA) may have some glitches, but feedback is fast and there is far less opportunity to go astray and deliver unneeded functionality
• Sometimes IT may run into a business user who dictates the technological solution rather than just give requirements. And who might also quickly and violently change requirements. In this case, it might be very hard for IT to push-back. One strategy that is being implemented in just such a case is to have the business user deliver his requests in batches. Anything making a certain cutoff time will be implemented and anything afterwards will make it in the next day. Another strategy is for IT to "cost" the list of remaining work items [i.e., Item 1 will take 3 hours, Item 2 will take 4 hours, etc] and have the Business User prioritize them himself. He'll know exactly what he's getting and when. He might even slow his requests down :)
  

2) Strategic Projects driven by IT

The way IT implements strategic solutions is long and cumbersome, falling back on a waterfall, BRUF (Big Requirements Up Front) approach. Stakeholders don't see value and in the interim, come back with more tactical projects that drive project plans and resources off-course. This type of project needs strong motivation and vision in IT. The initiative for this is most likely spawned by IT and sold to the business as a 'game-changer'. The threat here comes from being derailed by stakeholder demands for other projects (either because some other requirements arise or because they haven't seen any value come from the time/money spent so far).

The BRUF/Waterfall method is especially a threat to these IT driven strategic projects because of IT's tendency to want to do it right the first time. Months may go by without the stakeholders seeing a single screen and giving their feedback on the direction of the project. Without something tangible to go back to the business with to elicit real feedback, the development team may dream up something that is completely orthogonal or irrelevant to what is actually needed by end-users.

And when the system is actually delivered (most likely many, many months later), enthusiasm has waned and the system is so off-base from what was sold to the stakeholders that it is deemed un-usable or obsolete.

The biggest impediment to these types of projects is lack of stakeholder participation. Steps to combat this are:
1) Decrease time between 'selling the system to stakeholders' and delivery of a working system (even if its initial feature-set is limited)

2) Iterative Development and prototyping and involving stakeholders at each and every stage.