APPLICATION TO SOFTWARE ENGINEERING

   

graphics/application.gif

As I wrote the first edition of this book, my company was managing a project to develop a large software product for a major telecommunications company. The entire project was estimated to be in excess of 600 man-years, and would last several years . The project was in a very preliminary requirements-gathering phase.

There was at least one part of the project “ about 20 man-years of effort “ which had to be delivered by the end of 1993 at the latest. Let's look at the application of Step 1 of structured project management to that part of the project.

As I have stated earlier, it is important to identify what marks the end of the project. To some extent, this can be an almost arbitrary decision. For example, we might declare the day the software ships as the end of the project. A slightly better idea might be to declare the ship day plus, say, three months, as the end date. That would give us a chance to see what the customers think of the product. Let's do that then. Let's say that we expect to ship the product at the end of 1993, and three months later, we will declare the project over. By this we mean that we will move the product into a maintenance and enhancement project, and do an audit (see Chapter 10) as the last act of our project.

Thus, we expect this to be happening about the end of March 1994, all going well. Let's apply Step 1 by following the visualization checklist.

  • This project will actually be very significant to all of those involved in it. The organization my company is working with are a very new organization, and this will be their first major project and deliverable . All of the people working on it will be new to the organization, and bringing it in on time, on budget and producing a quality product will be a tremendous fillip to them. It will also enable the organization with which my company is working, to say to its customer (not to mention its parent) "we can do it, we have justified the faith you had in us."

  • We have focused very closely on the things the project will produce. We have done this by visualizing a software catalog in which all of the individual items which the project will deliver are listed. There is a core software product, three add-on modules, and two sets of documentation. When the project is finished, these things will be delivered to other project teams who will then build the much larger (600 man-year) system around our deliverables. The deliverables will also eventually go to the end customer, but that is a long time in the future.

  • We have already talked about what the project will mean to the members of the project team, and what their motivation might be in doing it.

  • The reason I want to do it is that this is the biggest project yet to which structured project management has been applied. I am excited to see how it will work.

  • What will life be like on the day/week the project completes? This question and others like it are ones which enable you to create the daydream we talked about earlier. It is one thing to talk about motivations and other grand ideas, but these are things that can change or drift out of focus with time. On the other hand, thinking about what you will do one day in the future, when a certain set of circumstances have come to pass, is a lot more concrete; and creates a vision which you can lock onto and carry with you.

  • What then will life be like when this project completes? It will be a day at the end of March. The customer will have had the product for three months by then, and we will know from the error reports coming in (or lack of them!) how successful it has been. What we would like would be that there were no error reports at all. (I once had this experience; for six months no errors were reported . And yes, the product was in use!)

  • To get back to the daydream: We will probably have planned a meeting for that day in March. There will probably have been a regular meeting ever since the product was shipped, to review how the customer was getting on, but this particular day will be the final meeting.

  • I will probably get up early, go for a run and then make my way into the office. I can picture in my head the people who will be at the meeting “ people from my company, people from my client's organization and (perhaps) people from the customer, though it is more likely that they will be indicating their acceptance of the product by e-mail, fax or phone.

  • We expect there to be a lot of happy people around that day. The client organization, pleased that their customer is saying nice things about the product and its robustness; the members of the project team, some of them perhaps already assigned to other projects but here for the last act but one of the project (the last act will be the audit); people from my company, pleased that we have delivered on what we set out to do.

  • The meeting will be brief, reviewing the errors reported over the last three months, logging what can be learned from them, spotting where the errors got through our checks, and planning that such things don't happen again. Maybe there will be champagne or cake or some form of little celebration . Maybe there will be bets to be settled (see Chapter 15 on problem solving!). Maybe there will be some nice comments about the product that we can savor for a while. Maybe there'll be a celebratory lunch .

  • OK, I'm sure you get the idea. This is a picture you can enhance and embellish either on paper or in your head, elaborating it with all sorts of incidents, people and words. What is important is to understand what you will feel when the project ends, because from that will stem your motivation. I know what I will feel: just a great sense of achievement, of happiness for the people who worked so hard to make it happen.

  • As regards what an audit will say about it, let's write down the answers we would like to be giving to the audit checklist.

  • Did we end up where we said we would? Yes. Exactly. The goal wasn't materially different from the predicted goal. It never changed and we were constantly aware that it hadn't.

  • Using the Estimating Score Card in Chapter 19 (or alternatively, reports generated by our project planning tool) we would have captured estimated versus actuals for the project, and we would be able to review these to understand where our estimating needed improvement.

  • We would like to be able to say that we did lots right and very little wrong, and here are the lessons we can learn from the things we did do wrong.

  • We would like to be able to say that very few surprises of any significance occurred; and again, of those that did, here are the lessons for the future.

  • We would like to be able to say that we didn't have to touch our margin for error; and if we did eat into it in any way, that again there are lessons.

  • These are all the things we'd like to be saying in a future audit of our project.

  • For my company, this project will be a major feather in its cap, and I will be hoping that we can use it as a springboard to other, larger projects. I'll be hoping that people will be saying that only a company like mine could have done a project like this as well as it was done. I'll be hoping that people will be saying it was a pleasure to work on the project and that they would like to work with my company again in the future.

  • Will my standard of living have changed? Come on, project management doesn't pay that well!

  • I don't think my view of myself will have changed, but it's nice for a relatively new company like mine to add something like this to its track record. I think the task we have set ourselves is difficult enough and has plenty of room for failure. I couldn't bear it if it did fail.

The remaining questions we have probably covered in the course of our ramblings. It's not essential that you answer them all, rather that you get into the thought process behind them. If you end up with a daydream that you can start to carry around in your head, then you can probably press on from Step 1.

   


How To Run Successful Projects III. The Silver Bullet
How to Run Successful Projects III: The Silver Bullet (3rd Edition)
ISBN: 0201748061
EAN: 2147483647
Year: 2001
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net