This is a guest post by Aren Cambre. Aren is a manager of web technologies at an educational institution. The way he explains it is, “If the web site looks like crap, they’re yelling at public affairs. If it’s broken, they’re yelling at me.” He has a M.S. Computer Science and is plodding towards a doctorate. His personal blog of random mis-mash is at http://arencambre.com.
Information technology (IT) focus is shifting from classical projects to agile services.
Here’s why.
Reason 1: Much of IT defies project definition
A classical project has a predetermined start, end, and result. When done, the result goes into “maintenance mode”, and you jump to the next project.
But what if something never has a “maintenance mode”?
For example, the web is never done. A university’s web site must be exciting and work quite well; the key audiences are technologically progressive prospective and current students. What university wants technophobic students? Relevant university sites must keep up with rapidly evolving consumer technologies.
A university’s web site is a good example of an agile service: an adaptive mix of agile applications and expertise. These are where a lot of IT’s attention is going.
Agile services don’t end. They are not classical projects.
Reason 2: Small projects don’t matter much
Isn’t a service just a lot of mini-projects? And isn’t the last trend to make projects smaller?
Neither matters much. Small projects are really large tasks or iterations in an agile project.
By themselves, small projects don’t tell the value of IT. Agile services do.
Reason 3: Virtualization and clouding
The largest classical IT projects are implementations. Virtualization and especially clouding make it easier to create new things, sometimes almost erasing implementation projects.
Taking away implementation focus shifts attention to maximizing value of existing investments. Again, emphasizing agile services at the cost of classical projects.
Reason 4: Agile is where it’s at
Classical projects use waterfall, a prescriptive method from the manufacturing and construction industries. It’s from a time when the pace was steady, change was resisted, and top down was how it happened.
Relevant IT is the opposite: fast-paced, adaptive, and responsive. That’s why agile project management is natural for IT: it encourages adaption, continual reassessment, early problem discovery, and faster completion.
I’m not the only one seeing this. A proxy is Atlassian JIRA versus Microsoft Project Server. JIRA is for agile, whereas Project Server is for waterfall. Look at their Google search trends (source):
But this isn’t just about improving how projects are done. Agile does something that waterfall can’t: manage services.
Paraphrasing Men In Black II, “Waterfall projects: old and busted. Agile services: new hotness.”
Do classical projects belong in IT?
To be clear, classical projects still have a place in relevant IT. Really complex projects aren’t entirely going away, and some may need waterfall. Same goes for projects with well-understood paths and vanilla outcomes.
However, “well-understood” and “vanilla” are starting to be outsourced, such as email, web systems, ERP systems, and more. If not outsourced, they may be heartbeat functions, increasingly undifferentiated from plant operations. Or their business value is not intrinsic; the value is in what others—users, innovators, developers—can wring from them.
Agile services are the future of IT. It’s how we work, it’s how we provide business value, and it’s how we communicate what we do.
Image Credit: Project Management Lifecycle By Ivan Walsh on flickr
33 responses to “Do projects matter for IT?”
Extremely informative article. Aren Cambre definitely knows what he’s talking about.
The company I work for uses AtTask, and as it is a work management tool, all types of work, from waterfall methods to agile project management, can be completed on this platform.
When Cambre says, “agile services are the future of IT,” I see three different reasons for this.
1) Elimination of geography – people can communicate the world in an instant.
2) Elimination of company hierarchy – “big boss” managers aren’t able to control by means of keeping employees at a distance.
3) Elimination of time stress – you know those days you wake up at noon, get a bite to eat before you run errands, and suddenly it’s already nighttime? Somehow, you don’t know where your day has gone. One distinct feature of agile, I think, is that it provides a real time history of how work is getting done, and in doing this, one can better manage time to the needs of both employees and customers.
Again, I’m impressed with this article.
Thanks Robert – AtTask is a nice platform…i’ve used it in the past. Great comment…thanks for stopping by.
This was a great article with some good information. I was not familiar with JIRA, so something new I need to check out. Thanks again!
@jeffpcox @arencambre put together a great post. thanks for stopping by!
@[email protected] ericdbrown No problem
Do projects matter for IT? http://eqent.me/mKOEZp
A totally awesome guy wrote this one. RT @EricDBrown: Do projects matter for IT? – guest post by @arencambre – http://t.co/AaVNbCj
Do projects matter for IT? http://restwrx.com/k1F9In via @EricDBrown
Hi Eric, thanks for publishing Aren’s article.
I’ve got a completely different view to the one articulated by Aren. I agree that there seem to be a shift towards Agile in IT projects but not for the reasons mentioned in the article.
1. I don’t believe it is correct to say that much of IT defines project definition. Using a web development example is a gross misrepresentation of what most IT project are like. Serious integration IT projects represent a level of complexity not found in normal web development and they do go into some form of maintenance mode.
2. I don’t believe small projects don’t matter much. If they don’t matter why do we do them in the first place. And what about the trend to make projects smaller. Projects get sized to meet the business problems for which they were created. Projects don’t get large or small but rather created in the size they need to be to deliver successfully.
3. Do virtualization and clouding really eliminate the need to have implementation projects? i can’t even begin to contemplate where this claim has come from and what logical foundation it is reliant on?
4. Agile and Waterfall are two valid methodologies, each with their own advantages and disadvantages. To suggest that one methodology is all but good and the other is all but bad is somewhat unscientific and blatantly biased.
Now, as I mentioned earlier, I still agree with the conclusion, that Agile is taking over. The reasons for this however are different to the ones presented in the article. In a nutshell, I believe that there is a positive correlation between the increase in the ratio of Gen-Y in the workforce, and the apparent drive towards Agile solutions. I’m not going to elaborate about it here as I’ve written about it in my blog (see http://quantmleap.com/blog/2011/03/is-the-time-ripe-for-the-agile-revolution/) but the bottom line is that Agile is certainly becoming more popular, though I believe not for the reasons mentioned in the article above.
Cheers, Shim.
I’m having difficulty agreeing with the article as well. First, I think a lot of the groups or projects shifting to Agile generally are coming from ill-defined adhoc methodologies more-so than a defined, waterfall methodology. I’ve seen far more adhoc methods claiming to be waterfall than I have true waterfall executions. It’s not enough to use a Gantt chart and have tasks planned out in detail from start to finish.
I think there are three main reasons that Agile methodologies are doing well in IT environments. Agile methodologies drive a certain set of things that our end users and stakeholders want. First, they drive deliver of some results sooner, incrementally providing chunks rather than trying to disappear behind doors for a year and then deliver the one, true working product. Agile methods also reduce the timeframe between requirements and delivery and assume that refinements will be made, which has a number of affects, from making the end users feel more involved and valuable to understanding that no one has 100% of the answer up front, ultimately providing a better fitting solution with less frustration. The third is that you can use Agile methodologies to manage work across a pool of projects or a mixed load of project work and support tasks, moving from a mode where we plan projects and the support calls get in the way to managing the flow of both.
I think these factors are particularly strong drivers for Agile in IT. We typically work on projects that have very complex requirements (how many times do we end up working on a dictionary just to build a simple tool?), a lot of IT environments are transitioning from poorly defined processes, and all of us are looking for ways to answer our stakeholders ongoing (and forever) desires to see results sooner.
And on the cloud movement, if you move all of the obvious implementation stuff to an external vendor then all you’re left with is the really hard systems and human integration aspects. The stuff that happens after you try to install a vanilla ERP and find out that even though all businesses have certain functions, they each have their own flavor, terminologies, and needs from those functions.
Do projects matter for IT? http://bit.ly/m9hvYK #DSIdufutur #v <= Agile services are the futur of IT.
Eric, Thanks for sharing Aren’s article but I think I am going to have to agree with Shim. I fear looking with the narrow lens of web projects grossly misrepresents the total IT project portfolio mix. I currently work for a large US financial institution and the web centric projects make up a relatively small portion of the total project budget. With matrixed IT teams and matrixed project resources with on-shore and off-shore resources it would be a significant challenge to Agile-ify the whole IT organization.
Another challenge not mentioned yet to Agile being mainstream is the traditional waterfall-esk IT budgeting cycles that exist in most mid to large IT shops. I’ve written about this challenge to Agile in the past on my blog here: http://bit.ly/bMqcua
Again, I commend Aren for bringing data into his arguments rather than just IT punditry. But, I think including a greater sample size of organizations will challenge the trends presented. Personally, if IT organizations could become more “agile” it would greatly help, just not seeing the trend as strong as Aren has presented.
#pmot Commented on "Do projects matter for IT? | Eric D. Brown" ( http://bit.ly/lvUhC8 )
@shim_marom #pmot Commented on "Do projects matter for IT? | Eric D. Brown" http://bit.ly/lvUhC8 <JB:commented and agree with Shim
@shim_marom Shim–I agree with a lot of what you’re saying.
#1 will depend on what your IT department does. Sorry if I made it sound like waterfall has no place; I meant to state the opposite with “classical projects still have a place in relevant IT”.
As technologies emerge and get both simpler and more powerful, expectations increase, hence the number of really complex projects may remain steady for some IT departments.
We in IT should hope for constantly increasing expectations. Our #1 job is to fill the gap between user expectations and what users are able to do for themselves, which increases every year.
On #2, smaller projects _do_ matter for the implementers and requesters and a layer or two of management, but I don’t see them as supremely relevant to explaining IT’s value as a whole.
#3–think turnkey solutions. Remember the mathematical concept where you find limits as an input approaches infinity? For example, what is lim y = 1/x as x approaches infinity? y = 0. So someday, a lot of very challenging implementations may be so dead simple that it’s not worth a project.
An example, if you needed a brand new email infrastructure 20 years ago, you probably had a complex project on your hands, especially when accounting for supporting technologies and infrastructure. Today? Just turn on Google Apps for your business.
Not everything is dead simple. But it’s not unreasonable to say that, assuming current trends, complexity of a given service-at today’s functionality level–approaches 0 as time goes on.
Now, as I said previously, expectations rise over time, so that’s a challenging skew. But will the technologies we use to meet future expectations increasingly approach “plug and play”? Another interesting limit theory question.
On #4, you’re wrong. Waterfall is old and busted. 🙂 (Just kidding!)
Aren
@jfbauer @shim_marom @Tarwn and @ArenCambre
Thanks for the comments (and @ArenCambre thanks for the post..love it)..
Do Projects matter in IT? The answer for me is – yes.. Will all IT projects move to agile – no. Should they? No. Waterfall has its place – as does agile.
For my thoughts on what seems like an age-old argument, go read https://ericbrown.com/agile-or-waterfalldoes-it-matter.htm. In that, I wrote:
It’s not necessarily the methodology used that causes failure or success in projects, it’s the way in which the organization is aligned that creates project success or failure. I truly believe that an organization can can choose whatever methodology they want to manage a project, but without proper organizational alignment and empowerment of the project managers and team members, the project most likely not succeed.
I still believe that today.
Thanks guys…love that you took the time to read and comment on this.
@Tarwn I like this: “I think a lot of the groups or projects shifting to Agile generally are coming from ill-defined adhoc methodologies more-so than a defined, waterfall methodology. . I’ve seen far more adhoc methods claiming to be waterfall than I have true waterfall executions.” I’ve seen a lot of agile proponents say the same about agile’s critics. 🙂 Basically, the allegation is that people mis-translate “agile” as “relax all process”. Their inevitable failure gets falsely pinned on Agile. I hadn’t thought of the opposite yet.
As for your cloud/ERP example, what about this: if you export ERP to the cloud, and it’s more than simply outsourcing your hardware, then there should be some enhancement of separation between infrastructure support from ERP management and development, maybe almost decoupling?
In this model, you unambiguously retain responsibility to configure or develop your ERP, which means you’re left with the ERP support functions that may be most suited to agile, and you reduce/drop the infrastrucutre-ish stuff which may not work as well with agile.
Now, full disclaimer–I am sure we can find concrete examples opposing my example. But what is the trend? Where do you expect things to be a decade from now?
@ericbrown : What does your crystal ball show on agile vs. waterfall over the next decade?
@ArenCambre I wish i had a crystal ball…i’d be rich 🙂
I think we see more of the same. Waterfall works well for some projects / companies and agile works well for others.
@ericbrown I’m closer to Alan Greenspan’s “irrational exuberance” for agile. 🙂
Do projects matter for IT? http://goo.gl/mZ7Nf #pmot
@[email protected]_marom
I’m happy we’re still friends mate. There’s nothing better than a good healthy argument.
Cheers, Shim..
Some excellent comments / convo here -> Do projects matter for IT? http://t.co/AaVNbCj
RT @ericdbrown: Some excellent comments / convo here -> Do projects matter for IT? http://t.co/AaVNbCj
RT @ericdbrown: Some excellent comments / convo here -> Do projects matter for IT? http://t.co/AaVNbCj
Some excellent comments / convo here -> Do projects matter for IT? http://t.co/AaVNbCj
@shim_marom #pmot Commented on "Do projects matter for IT? | Eric D. Brown" http://bit.ly/lvUhC8 <JB:commented and agree with Shim
Do projects matter for IT? http://goo.gl/mZ7Nf #pmot
Do projects matter for IT? http://t.co/IGSzy16
[…] Visit https://ericbrown.com/do-projects-matter-for-it.htm for a recent article I wrote on projects in IT. […]
Good information you are providing about projects. Keep going on..
Unleashpm.com
[…] Educause’s recent Outsource the Transactional, Keep the Transformative complements my recent article questioning the value of projects. […]
[…] posted on Eric Brown’s Technology, Strategy, People & Projects blog on June 7, 2011, with some […]