|
|
|
| |
| ||
 |
Predictive versus Inventive Projects In his book Agile & Iterative Development – A Manager’s Guide, Craig Larman defines two broad categories of projects: Predictive projects for which all the required work can be defined upfront with a high degree of confidence that work will remain stable throughout the project life cycle; and Inventive projects for which the required work cannot be defined upfront but must evolve over the time and require a life cycle that accomodates that evolution. softwareDecisions believes that software development projects should be inventive. If they are not, there may not be sufficient business value created to justify the project. | |
|
|
36 Classic Mistakes Steve McConnell, in Rapid Development, defines 36 classic mistakes related to people, process, product and technology issues that often committed on software development projects. The author goes on to makes the point that many organizations looking for a “rapid” development method really don’t need one. What they need is an “effective” development method. softwareDecisions has found this list to be a real world assessment of those things that often go wrong. Want to get improved results from your software development project? A good start would be to ask yourself how many of these mistakes are being made on your project. The answer might surprise you. | |
|
|
Software Development as a Core Competency In his keynote address at the 2004 Software Development Conference West, Grady Booch spoke to making software development a core competency of the business, and thereby using software development to create strategic advantages over the competition. softwareDecisions believes too many organizations don’t integrate software development into their overall business process well enough; often losing the opportunity to create on-going business value. | |
|
|
Getting the Right People on the Bus Good to Great, by Jim Collins, has nothing to do with software development or even information technology. Collins conducted an extensive study of why some companies “make the leap” while others do not. His research examined why companies like Gillette, Kroger, and Pitney Bowes outperformed their competition by showing returns of at least three times the market over a period of 15 years or more. One of the five keys Collins found is that these organizations built their management team with the right people, often hiring them without specific positions in mind (getting the right people on the bus), and placing them in the right roles (getting them in the right seats on the bus). Equally important was getting the wrong people off the bus. softwareDecisions believes that software development is a collaborative effort of a team of like minded professionals focused on a common goal. It is not, as too often practiced, the herculean effort of one or more stars. Getting the right people on the team (and the wrong people off) is a key to success. No star is more important than the team, and no star, by himself, can match the results produced by a cohesive team. Getting the right people on the team performing the right roles is the first major step toward success. |
|
|
|
Conscious, Unconscious and Undreamed Requirements The Cutter Consortium study, Next Practices in Requirements Engineering by James Robertson, Suzanne Robertson, Ken Orr, and E.M. Bennatan discusses three types of requirements. Conscious requirements are what your stakeholders are most likely to tell you about. They are what a user would tell you about in describing his day-to-day activities. Unconscious requirements are those that a stakeholder does not think to mention. Perhaps something that is so obvious to the stakeholder that he doesn’t consider it worth mentioning, if he thinks about it at all. Undreamed requirements are not asked for. They might be something that the stakeholder does not think is possible, or something that is too far removed from the stakeholder’s perception to even consider. softwareDecisions believes that development efforts must be proactive in gathering requirements. No set of stakeholders will simply tell you the right set of requirements. Discovery efforts are needed to seek out the unconscious and undreamed requirements in particular, as these are the requirements that make or break your project. | |
