Category Archives: Software Project Management

Posts about software project management in general

Agile and Fixed Price Projects

I was meeting with some local developers the other night and one of the topics that came up was how to move from traditional fixed price projects to agile ones. The developer I was chatting with works for a firm that submits tenders to projects, where the clients all expect, and want fixed prices for the project so that they can submit their budget. His experience in trying to move to agile projects was that these are hard to tender because their costs look too high, and then they end up being undercut on price by competitors.

There has to be a way to do this: make this transition so that clients know you can do the work and do the work as required to meet their requirements. However, I’ve not found much on the topic on the interweb. Have I just missed the memo, or is it hidden somewhere? Surely others have gone down this road too, and written about it?

What I did find was a few links to useful papers and experiences. Start with the two pieces (part 1 and part 2) by Pascal Van Cauwenberghe under the ‘reading and books‘ page. Vikrama Dhiman also has a few points on fixed price projects on his blog, but argues the counterpoint to Pascal, so maybe that issue about ‘bidding low’ is up for debate.

My own feeling is that agile and evo teams should be able to make a compelling offer as part of their tender on projects, much as Goldratt discusses in ‘It’s not Luck‘. This needs to be a way to get the point across to those submitting RFTs that your offer will deliver something more useful than the spec provided, in a shorter time, and thus for less money in the long run. Maybe I need to find a firm that wants to pursue this further and we can work on it together. There must be a better way.

Industrial Experience at Leeds, Kent and Sheffield

While at the University of Kent in Cantebury last week for the HEA-ICS conference I had a chance to discuss some of the other programmes that offer students places in software houses either as part of their undergraduate programme, or as an extra job for which they need to apply for a place. At Kent and Sheffield this can be done as part of the programme, while at Leeds this is an extra done outside of the curriculum.

About three years ago the University of Kent started their IT Clinic programme based upon the Genesys Solutions programme at the University of Sheffield. Last night I was able to speak to someone at Kent who’s worked with the IT Clinic. He told me about the programme at Sheffield, which I looked up later. Some of the interesting things about both of them are that they are integrated into the curriculum for the undergraduates and the postgraduate students. This means that the students are getting course credits for the work they do, and that the ‘work’ the business brings in is also separated from the ‘processes’ of project management and development, upon which they are assessed. At Kent the IT Clinic is also only one stream of many, which the students can do for their degree, as it is not something that all students will want to pursue.

At Sheffield all students do group projects as part of the ‘Software Hut‘ (link to course site), which explicitly uses extreme programming, TDD and pair programming as part of the process from the very beginning of the term. Once they have done this module, then they can go and do further development and project work in the Genesys Solutions office for credit and gain further experience. The projects for the Software Hut are for external clients, but each client might have four teams competing to build the ‘best’ solution for that client, with the ‘winning’ one chosen by the client being the one implemented in the end. This is an intriguing idea, but I’d have thought it would be a waste of time, as the client doesn’t get any results until much later, and they work with a fake luxury of multiple prototypes that can be tried and tested, which is not the usual way things work.

At Leeds the students can apply to take part in the Leeds Source-IT consultancy project. This is a new venture, which started around February of this year as a way for students to gain more practical experience, while also providing a service to the community. A key issue, which they have noticed is that students can only work about five hours a week on their projects during term time, to allow for their time for coursework. Needless to say, this proves limiting in how much work the team can take on at any one time.

One difference with the Kent solution is that it is as much about software development as it anything else, which can be a project. Therefore the consultants there will do laptop clinics to help students out at the start of term, and they’ll also do other hardware projects, and not just focus on software. On the one hand this can be a useful awareness raising activity, but on the other, it is diverting attention away from learning the tools of the trade in software engineering. Focusing on software will also look better on the cv for the student too, when she or he comes to apply for work after they finish their degree.

Both Kent, and presumably Sheffield too, have staff who look after the programme finding clients for the teams. In Kent, they have hired outside consultants, who worked in the region previously and therefore had good understanding of the local market. At Leeds they have someone who looks after all of the student related programmes in the department to look after this one too.

I think I need to plan a path that gets our programme to such a state as simply and naturally (ie as organically in a natural progression) as possible. Establish the components, glue the components together in a path students can take, and show their value to the department as a whole. This is the next step in this project.

UPDATE: (10 Sept) Forgot to mention Philip Greenspun’s ideas on universities and the economy and how the curricula students encounter with project based learning can help the local economy and prepare students for the working world. While he doesn’t push a software house for students, he does provide industrial relevant projects for students to develop.

EVO: Measurable Value in the Classroom

The other week as part of the summer conversion MSc group project preperations I took the Measurable Value case study by Ryan Shriver and turned it into a working example that the students needed to work through. This exercise worked, but could’ve been better. Ryan also gave me permission to make use of his example as I wanted, so I reused his materials where it seemed appropriate. Thanks Ryan!

Shriver works through a clear voluntary organistion example, and provides the answers along the way, as you do with an article. I decided that the students would need to hunt for their answers amongst some worksheets that I would give them. After looking round I found some similar materials  centered around Impact GiveBack, and some relevant news items that I could reduce to workable data. With this in hand we could then work through Shriver’s six steps of Evo.

The other links that had usable background information were: http://online.wsj.com/article/SB121554292423936539.html http://www.newsweek.com/id/62168 (26 Oct 2007 issue) http://www.slate.com/id/2183542/pagenum/all/#p2 and some made up data about goals for volunteer hours and donations that I extrapolated from the data found elsewhere. This meant that the students had something to look through in their hands, and didn’t need to go hunting on the internet to find information. Hmm, that might be interesting to do as part of an ongoing project perhaps, if each team had to do an extended scenario.

Earlier in the day I’d gone through a reduced slideset of  a talk by Tom Gilb in October 2007 to put Evo into context and explain how it approached software engineering and project management. This seemed to go fine, and followed other discussions about waterfall and agile approaches in general. Therefore the general groundwork was laid we were explaining why Evo is required, and how it is used in conjunction with agile projects.

Working through the six steps that Shriver sets out, and approaching the case study the same way that he did, worked well. I could set up the issue and then point the students to the handouts which they discussed in groups around tables. After ten minutes or so, then I gathered up answers on the blackboard and we discussed the solutions provided for that step. Instead of gathering up solutions verbally, a better approach might be to have the teams submit written solutions, which could then be merged at the front of the classroom, so that no group feels there solution was ignored because another group listed it before them.

The only problem encountered was with creating workable impact estimation tables based on Shriver’s spreadsheets. I showed them his examples and how they could be used. A better job next time would be to prepare his examples a bit further, and clarify how the IET relates to the data from our examples, instead of showing completed ones for his example, which was similar, but not quite the same. Providing partially completed ones would mean that they could then fill in the rest per the data they have for the scenario, instead of reading what’s on the ones Shriver used.

All in all, this worked, and I’ll definately use it again next year after I make the suggestions noted above. Having people work through the scenario themselves gives them a feel for the approach, and how it is applied. Having a reading to take away that uses an example similar to the one they worked through themselves is priceless. So far so good, and the projects now seem to be starting off without too much trouble.

Still problems with software development

There is a new 2009 Chaos Report from the Standish Group. It still shows the poor success rate for software projects, and that many are still challenged with budget and delivery issues. Things are not any better since the 2006 Chaos Report either. They are somewhat better than the original 1994 (or at scribd) report at least.

  • Successful projects (on time, on budget with requested features): 32% in 2009, 35% in 2006, 16.2% in 1994
  • Failed projects (cancelled prior to completion):  24% in 2009, 19% in 2006, 31.1% in 1994.
  • ‘Challenged’ projects (over budget, missing features, late deliveries): 44% in 2009, 46% in 2006, 52.7% in 1994

According to the above the situation has actually gotten worse, except that now fewer are ‘challenged’ than in the past. We are not deliverying more successful projects, and the likelyhood has increased that the project will fail.

On the one hand, it is sad that these sorts of results still appear, despite the trends towards more adaptable and flexible project management and software development practices such associted with agile. You’d hope and assume that best practices would spread around the industry and we’d all get better at building software applications. Obviously not, if you think about the UK NHS software project and it’s ongoing mess.

On the other hand, as pointed out by Glen Alleman, we don’t know the basis of the Chaos Reports: how many firms were questioned, how many replied, is this a real sample of all projects, or of just the ones covered in their survey? We don’t know, so we can take the results with a pinch of salt.

As Pavel Brodzinski argues, everyone knows about these reports, so the results don’t make a big impact. Only a few teams, he says, will bother to train themselves to be better.

If you think about it though, that is sad too. People are stuck in a rut and like to stay in their comfort zone.

It does present an opportunity though for those firms which do finish their projects on time, and on budget and with the features requested by the customer. They have new stats to use in their marketing. They should also be able to keep bringing in clients on a regular basis if they can show a proven track record of successful projects.

Update 19 May 2009: Found a reference to a paper given by Jim Johnson of the Standish Group at XP2002 on ROI that had results of Chaos Report 2000, that were just as dire as others. The idea pressed here was to focus on early results, customer involvement and to keep the project small if you want to be successful.

AgileScotland workshop coming up

Clarke Ching is setting up another AgileScotland workshop in Edinburgh for the near future ‘before summer’ as he says. The theme is ‘using agile to save your job‘ and will be a mixture of ‘how to do agile’ and experience reports.

I went to one of his workshops last year and found it real useful. As I was still new to agile at the time, I found it a good experience to codify, and bring out more, aspects of agile that I’d read about in various places, but not discussed with others.

I’m looking forward to getting to this event and hope that it is before the industrial group projects start so that I can take what I get from that event and apply it to the new work of the teams. Fingers crossed that this happens at a time that I can make it.

Agile industrial experience for students

Students, especially the MSc students, are always wanting to have industry related projects. One way to do this is to get industry to come to us for software projects. This will not happen overnight however. I’m sure the other universities who’ve done this also started small. Some sound impressive, and are relevance to what we might do. Bowling Green State University in Ohio has an Agile Software Factory, which provides a number of ways for students to participate. New Mexico Highland University also had a similar type of programme too. Closer to home, Kent has the Kent IT Clinic, which uses students to provide light services to local SMEs.

So we can kickstart our efforts in this direction, as noted previously, by going to a local organisation for possible partners. This should work if we can align the possible projects within some basic constraints of projects.

The new student experience should come through developing real applications for local organisations as part of their group projects. The local organisation benefits from having a real application developed for which they’ve previously identified a need and the students gain experience working with real clients as part of a real software development team.

At the moment this is at a trial stage and some pilot projects need to be found for development over the coming summer of 2009. The potential projects should have a few specific characteristics:

  •  Achievable over a twelve to fifteen week period with a workable product at the end, which the organisation can use.
  •  A client whom the students can liaise with on a weekly basis, and whom they can email or phone as required in order to answer questions about the product.
  •  An application that is needed with suitable interaction to meet the needs of a group project. This could be a desktop application, or web application used by staff to fill in forms, or to streamline other business workflow. An ecommerce application would also be suitable.

The project will demand consistent regular input from the client, so that they can help guide the project direction, and so that the direction can be checked and corrected as required. It also means the students will not be stuck waiting for input before they implement a feature of the application.

All projects should follow an agile plus evo approach building upon Ryan Shriver’s approach. This means that they will be done iteratively and incrementally with suitable measurable outputs as to how well each component, will meet the desired business goal of the project. This also means the project will demand consistent regular input from the client, and that there will be a number of points at which the project direction can be checked and corrected as required.

The students who will be doing this pilot come from two different programmes. Neither of them have studied agile or evo before. One group did a typical software engineering and UML course last autumn. The other group has not done this module yet, and will do it later. This is not ideal, but you do what you can.

These students will need a preparation period to learn the processes they need to successfully deliver the product to the clients, and they will also need to learn the reasons for the processes they are learning. If they don’t know the ‘why’ of what they are doing, then they will not apply the ‘how’ they are being asked to complete.

The students need to learn the ‘what’ of agile and evo so that they understand what the life cycle is they are using for their projects. Part of the ‘what’ is also the ‘why’ of using agile and evo compared to the traditional waterfall or spiral life cycles of software development. There are a number of resources available, which cover these aspects.

More pressing is the issue of the students learning the ‘how’ of agile and evo. They need to know and understand the daily practice of agile and evo so that it is successfully implemented to provide a successful (usable) business product for the customer at the end of the project. While there are a number of resources available describing these practices, it would also be useful to tie these in with a series of workshops so that the students can learn the processes before applying them to a real project.

In order for this industrial experience to be successful in the long run more people will be needed to manage the teams and guide them. We will need staff to also participate in the workshops so that they too can help guide the student groups on their projects in a suitable manner.

The main goal of this pilot period is to uncover any issues, which need to be resolved before the scheme can be scaled up to include more organisations, and more student groups. Over time this should become a regular service available to local organisations. In order for this to happen, however a trial project or two is needed to establish its feasibility.