[Reprint] What is a "successful project": Talking about the value of software

Off Topic:

As a result of career planning needs, start new career challenges, join a new company, start Project management work, thanks to the trust and support of Shinto, give me this opportunity, I will devote more energy to the next work to achieve perfection, for the company to create greater value.
Do a good job in project management and think about what is a successful project? What is a successful project manager? What can be done to better guarantee the success of the project? How to institutionalize, systematic, process-based, information construction enterprise management?
In fact, it will be found that project management is an eternal topic, small and medium-sized companies are not the same project management confusion, large companies more systematic project management method is not suitable to explore the "national conditions" of the project management method.

The original text reads as follows:

Before I begin, I'd like to start with two stories-stories about software projects.

Story One

There are two software projects (referred to as "project A" and "Project B"), and they start with a budget of 50 people and a 5-month period.

• Project A is completed in 5 months, costing 50 people months
• Project B completed in 6 months, costing 70 people months

Readers who have been in the software circle for years must have their own judgments about the story-and I can guess roughly what the judgment is. But let's not worry, we have another story.

Story Two

There are two software projects (still referred to as "project A" and "Project B"), and they are initially planned to deliver 200 functions.

• Project A delivered initially planned 200 functions at the end of the project, but the customer found that about 30 of these features were not very useful, while the other 30 useful features were not implemented until the next project.
• Project B delivered the first version at the end of the first month, and a new version is delivered every two weeks thereafter. In the course of the project, the customer made a business adjustment, added 90 new functions, and shelved 50 less useful functions. Finally, the project delivered 240 functions.

The smart reader probably noticed that the two stories were about the same thing, the same two projects. Now my question comes: Which project is the more successful project?

The question is not easy to answer-in fact it has no standard answer. In the standpoint of many software companies, Project A is an ideal success Project: To complete the pre-agreed tasks by time and cost. Please note that I used the word "ideal" and I'll explain the interesting word later, because software projects are often less than ideal.

And if we change an angle, how do you stand on the customer's position? Maybe the customers who pay for the software will have some different ideas. Project B delivered the first working version one months after the start, and since then the customer has been using some of the software's features and has constantly fed back to the development team the feelings they use. In the real business process, the customer even found a new profit model, and a large-scale business adjustment, the results of this adjustment is also intuitively reflected in the software project. While Project B's overall delivery rate is lower than project A, it provides all the functionality that customers really need, providing real value to their customers-not to mention, customers start using the software months in advance.

In fact, this is an article about the value of software . Like "Successful projects", different people have different definitions for "The value of software". But as a customer who pays for the software, his definition of software value is clear: How much value he can create from using the software, how much value the software can provide for his business, and that is the value of the software. Or, to be more concise:

software value derived from use

That's why a lot of customers favor "project B"-I'm not going to claim that all customers have the same opinion, and I'll cite a counter-example later on, but there are a few customers who support this view at least. Because they are in a brutal and fast-changing business environment: their suppliers are changing, their customers are changing, the economic environment and the policy environment they are in are changing. All this change is forcing their business to change as well. What's more, today's era of economic globalization is a "fast fish eating Slow fish" era, customers are desperate for new software systems to bring them a competitive advantage-even if the software system is not yet complete, as long as it can be put into use. Finally, customers are not entirely sure what the new software system should look like, and their ideas tend to emerge after they actually use the software. The combination of factors that make these customers more willing to start using the software as quickly as possible, provide feedback, and constantly refine the software, rather than presenting a set of requirements and then waiting for months to get those features intact.

A real case.

In a project in ThoughtWorks, developers released the first version within one months of the start of the project-with some simple data collection capabilities. At the launch of the exhibition, such a dialogue took place ...

• Developer: This is our first feature. We collect data from text files, Excel datasheets, and legacy databases, and now we have this data in our database ... (Presentation database structure)
• customer: hmm ... Interesting. If you can make such a query (write out the query request), the resulting results may be useful.
• Developer: But there is no place on our interface to do such a query operation.
• Customer: Ah, I do not need to operate the interface, as long as every night to do a query, the report sent to my mailbox on it.
• Developer: so ... Another problem is that it takes us a few days.
• Customer: no matter, put other tasks back for a few days, I would like to see this statement.
• Developer: Well, we'll start providing this report next week.

Guess what the result is? A week later the customer starts receiving the report daily and makes some analysis and decisions based on the content of the report. Only a few months later, the report's benefits to customers exceeded the investment of the entire project-and the development of the rest of the project was not even completed.

Think about how the customer would define a "successful software project"? Well, maybe the project exceeded the expected time, maybe more manpower, but that doesn't mean "project failure" – it's just a higher cost. The key is how much money he puts into the costs, and whether his return on investment is a bargain. For this client, if the project is ready to provide him with the software that is available to create the most value, it can be done at any time-as the story says-and this valuable idea is a successful project.

So, dear reader, please forget the word "agile" appearing in the title of this article, what we are talking about here is not something else, it is a software development method that creates maximum value for customers. There are many ways to do this, but they have one common feature: as soon as possible, to deliver the work-ready software as quickly and as often as possible, allowing customers to start using the software as quickly as they can, creating value from use, clarifying ideas, and giving feedback. Still taking the ThoughtWorks project as an example, these projects usually release the first version within one months of the start of the development phase, followed by a new release every week or every two weeks-each version is a working software, each version has a richer feature than the previous version. And each version contains the features that customers think are the most valuable to date. The "slang" of software development, the "development of the next version" process is called "iteration", the most common denominator of these development methods is "iterative development"-not a single brain to deliver all the functionality, but every time to add a little, incremental delivery of the most valuable features.

The dream and reality of software development

Return to the two stories at the beginning of the article. I have said that for many software companies, project A is an "ideal" success project. So what makes the situation less than ideal?

The answer is a familiar word for all software developers: changes in requirements. In real-world projects, customers usually don't wait until the last day to take the whole project, because he knows his business is changing. This is when demand changes arise, accompanied by wrangling and bargaining. To make things worse, a lot of changes in demand took place late in the project--because until then the customer actually saw and used the software, many of his ideas really surfaced. With this "Last minute demand Change", the project is overdue and out of budget is a commonplace. Being able to deliver as finished as project A is a rare and lucky one.

To counter the nightmare of demand change, software developers have invented another word: change control. The interesting word implies that demand change is a "bad" thing, something that needs to be "controlled". But is it not the most valuable thing to think about the customer's point of view when he has personally used the software to ask for it? Is it reasonable to "control" the demand that truly creates business value?

As I hinted earlier, not all customers are bound to favor iterative development. So, what software projects do not necessarily need iterative development? From the content of the whole article is not difficult to see, if the customer's business will not change, if the customer's needs are very clear, if the customer does not need to start using the software as soon as possible to recover costs, then the iterative development of his help will be much smaller. However, if the reader is seriously thinking, this may not be a lot-perhaps much less than you initially thought. A good example is the computer control system used by the "Shenzhou Sixth" rocket. How many such examples are there? Readers may wish to try their own thinking.

If I'm lucky enough, maybe some readers have been suspended from this article: since there is such a good software development method, since it can create more value for us, then what is waiting, we will do it immediately. Things won't be that simple. In order for iterative development to be a reality, we-including software developers, software companies, and customers-require a lot of change in order to ensure that they are delivered as quickly and as frequently as possible, in order to ensure that each delivery is the most valuable feature. There is the division of responsibilities and rights, the development process and the reorganization of the team, as well as the technical aspects of practical guidance. These are exactly what agile jurisprudence covers. The lack of these things, "to create maximum value for customers" can only become an empty word. In the following article, we will combine ThoughtWorks's practical experience to introduce the agile approach in every aspect.

The original commentary has several points worth pondering:

Re: Can you introduce the experience of agile in product development? March 30, 2007 12:25 by Xiong Jeff

can you introduce the experience of agile in product development?
Every version of product development uses fixed requirements, and agility requires change.
Which parts of agile can be referenced in product development?

For agile experiences in product development, see the relevant discussions in agile China:
Groups.google.com/group/agilechina/browse_threa ... There's a problem you want to talk about.April 1, 2007 02:02 by Liu DF The improved customer engagement in the article is certainly ideal (for customers), but one thing is overlooked: the interests of the development team.
From China's current project implementation, said, basically is the system on-line acceptance after the payment. Hehe, it seems that if the customer's needs are constantly changing, then it is always impossible to accept, then the development team cost how to maintain it. I hope we can discuss the solution of this practical problem, otherwise the topic will be a bit of ideal. Re: There's a problem you want to talk about.April 1, 2007 08:49 by Zhu Pan I also want to make clear that the user's requirements change may be endless, but money can not endlessly give, when the end of the iteration? a business problem .April 22, 2007 08:31 by ke cake If the requirements of the project change frequently, how can the enterprise guarantee to profit from the project? How do I sign a business contract?

Blog to: The author of theInfoQ Bear Festival released on March 26, 2007, "What is a successful project": Talking about the value of software

[Reprint] What is a "successful project": Talking about the value of software