A successful project requires diverse skills

My introduction to the Pentaho suite (and specifically the "Spoon" and "Kettle" tools) gave me some insight into necessary skills for a successful project.

For a successful development project, you need several, diverse skills. All are important. Without any of them, the project will suffer and possibly fail.

Assuming that your project will use some tools (compilers, web servers, whatever), you need the skills necessary to use the tools. How the they work. How they open files and read data. Which widgets are included and what they do. (Microsoft .NET has a problem with its widgets: there are too many of them. When building a solution, you must either use pre-built widgets or make your own. The .NET class collection is larger than a single person can comprehend, so you always fear that you are missing out on a simpler solution from a more powerful widget.)

Second is knowledge of the business resources. What data is available? How is the data named? Where is it stored? Most importantly, what does it mean? As with widgets, some data domains have "too much" data, such that a single person can never be sure that they have the right data. (Large organizations tend to have analysts dedicated to the storage and retrieval of data.) Beyond data, you need awareness of servers and network resources.

Third is knowledge of the business environment. What external requirements (regulations) affect your solution? What are the self-imposed requirements (policies)? What about authentication and data retention?

Fourth is the ability to interact with business folks and understand the requirements for the specific task or tasks. (What, exactly, should be on the report? What is its purpose? Who will be using it? What decisions do they make?)

Finally, we have programming skills. The notions of iteration, selection, and computation are needed to build a workable solution. You can lump in the skills of iterative development (extreme programming, agile development, or any set you like). Once you understand the tool and the data available, you must compose a solution. It's one thing to know the tools and the problem domain, it's another to assemble a solution. It is these skills that make one a programmer.

Some organizations break the development of a system into multiple tasks, assigning different pieces to different individuals. This division of labor allows for specialization and (so managers hope) efficiency. Yet it also opens the organization to other problems: you need an architect overseeing the entire system to ensure that the pieces fit, and it is easy for an organization to fall into political bickering over the different subtasks.

Regardless of your approach (one person or a team of people), you need all of these skills.