Hands on in All Phases

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(New page: Each project is different, each one is special. And still, my experience is that there is no more significant factor to project success, than programmers who have previously worked in succ...)
Current revision (06:34, 7 August 2009) (edit) (undo)
 
(2 intermediate revisions not shown.)
Line 1: Line 1:
-
Each project is different, each one is special.
+
Each project is different, each one is special. And yet, my experience is that there is no more significant factor to project success than the presence of programmers who have previously worked on successful projects. It seems that there are skills to learn on successful projects that you just cannot learn elsewhere. Among them are those human factors such as communication and attitude, at least those that one can learn somehow.
-
And still, my experience is that there is no more significant factor to project success, than programmers who have previously worked in successful projects.
+
-
It seems that there are skills to learn while joining successful projects, that you just cannot learn elsewhere. Among them are those human factors like communication and attitude, at least those that one can learn somehow.
+
-
Now, project success is created in each single phase of the project. It is easy to know that a project can be doomed while it is still in acquisition or in definition. But it is hard to know how this can be influenced, and what to do there. And it is even harder to know what you can do about doom factors that you spot lateron.
+
Project success is created in each single phase of the project. It may be easy to determine that a project is doomed while it is still in acquisition or in definition. But it is harder to know how this can be influenced, and what to do there. And it is even harder to know what you can do about indications of doom that you spot later on. Furthermore, before the software is ready, the project is not finished. Again, it is easy to know that a project may fail almost touching the finishing line. The hard part is knowing the difference between the finishing line, and almost the finishing line. And what to do to bridge this gap.
-
Furthermore, before the software is ready, the project is not finished. Again, it is easy to know that a project may fail almost touching the finishing line. The hard part is knowing the difference between the finishing line, and almost the finishing line. And what to do to bridge this gap.
+
-
Actually, there are books and courses on all these topics. Reading them, attending them you will learn a lot, gain great insights, and you will be able to speak fluently about any projects potential. Still, there is a difference between experience, and reading.
+
The initiation and the finalization of a project are more tightly linked than you can possibly learn in class. It is extremely helpful to have project team members who can sense the outcome of certain early decisions. And who is most likely to be able to sense this? And to determine possible ways out of unpleasant situations late in the project? Let's consider one possible scenario. There is a project starting, possibly with an acquisition by some consulting company. Now there are the smartest consultants ever, convincing the customer that they can do the best job. Would you trust the estimates and the requirements of some smart guys, that have never seen the end of a project?
-
So here is the career advice. Attend successful projects.
+
There are books and blogs, and conferences and courses on all these topics. Reading them and attending them you will learn a lot, gain great insights, and you will be able to speak confidently about any project's potential. Still, there is a difference between active and passive learning, between experience and reading, between doing and watching.
 +
 
 +
So here is the career-making advice: attend successful projects.
Join projects in whatever phase, and strive to make them successful. Take care that while you see more projects, that you actively join each phase at least once.
Join projects in whatever phase, and strive to make them successful. Take care that while you see more projects, that you actively join each phase at least once.
-
If you happen to join a team or company that fails to complete projects, leave. Not as quickly as possible - you might contribute to success, after all, and there is also a lot of learning in failure (1). But you need your opportunity to join a successful project, and to join each phase of a successful project.
+
If you happen to join a team or company that fails to complete projects, leave. Not as quickly as possible — you might contribute to success, after all, and there is also a lot of learning in failure. But you need your opportunity to join a successful project, and to join each phase of a successful project.
 +
 
 +
 
 +
: ''She knows there's no success like failure''
 +
: ''And that failure's no success at all.''
 +
: Bob Dylan, "Love Minus Zero/No Limit"
 +
 
 +
 
 +
By [[Klaus Marquardt]]
 +
 
 +
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
-
(1) "There is no success like failure, and a failure is no success at all". Bob Dylan, Love minus zero - no limits.
+
Back to [[97 Things Every Programmer Should Know]] home page

Current revision

Each project is different, each one is special. And yet, my experience is that there is no more significant factor to project success than the presence of programmers who have previously worked on successful projects. It seems that there are skills to learn on successful projects that you just cannot learn elsewhere. Among them are those human factors such as communication and attitude, at least those that one can learn somehow.

Project success is created in each single phase of the project. It may be easy to determine that a project is doomed while it is still in acquisition or in definition. But it is harder to know how this can be influenced, and what to do there. And it is even harder to know what you can do about indications of doom that you spot later on. Furthermore, before the software is ready, the project is not finished. Again, it is easy to know that a project may fail almost touching the finishing line. The hard part is knowing the difference between the finishing line, and almost the finishing line. And what to do to bridge this gap.

The initiation and the finalization of a project are more tightly linked than you can possibly learn in class. It is extremely helpful to have project team members who can sense the outcome of certain early decisions. And who is most likely to be able to sense this? And to determine possible ways out of unpleasant situations late in the project? Let's consider one possible scenario. There is a project starting, possibly with an acquisition by some consulting company. Now there are the smartest consultants ever, convincing the customer that they can do the best job. Would you trust the estimates and the requirements of some smart guys, that have never seen the end of a project?

There are books and blogs, and conferences and courses on all these topics. Reading them and attending them you will learn a lot, gain great insights, and you will be able to speak confidently about any project's potential. Still, there is a difference between active and passive learning, between experience and reading, between doing and watching.

So here is the career-making advice: attend successful projects.

Join projects in whatever phase, and strive to make them successful. Take care that while you see more projects, that you actively join each phase at least once.

If you happen to join a team or company that fails to complete projects, leave. Not as quickly as possible — you might contribute to success, after all, and there is also a lot of learning in failure. But you need your opportunity to join a successful project, and to join each phase of a successful project.


She knows there's no success like failure
And that failure's no success at all.
Bob Dylan, "Love Minus Zero/No Limit"


By Klaus Marquardt

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Programmer Should Know home page

Personal tools