iMadalina on .Life

• It takes one woman nine months to have a baby. It cannot be done in one month by impregnating nine women.
• Nothing is impossible for the person who doesn't have to do it.
• You can con a sucker into committing to an impossible deadline, but you cannot con him into meeting it.
• At the heart of every large project is a small project trying to get out.
• A problem shared is a buck passed.

http://agilemanifesto.org/principles.html

Here is an extract from the Agile Manifesto:

" Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. "

I regarded the affirmation above as a personal one, as a belief that a project manager never forgets at the beginning of a new journey – a new project.

I looked at the statement from all the different angles that I could find… but no matter how I did it, I always stumbled upon ONE single aspect: “if the CLIENT so desires…”

Ok, how things are done depends on the area the project relies on. If the project implies building a spaceship, the moment you put an end to analysis and design is the moment you know that changes that may come, if they come, are caused by real issues that arise along the way, inevitable situations independent of methodology, “life and death” scenarios, changes that you cannot, should not and do not want to ignore, changes that may trigger the success or failure of the whole project. But these are issues of external factors and Risk Management maybe…

When it comes to software related projects, things should somehow be different. At least from my point of view. The aspects involved in a software solution are usually pretty clear - we know the premises, what result will be obtained and how to obtain it. All of that due to the fact that analysis doesn’t only stand for the stage in which the developer reads the documentation and, based on it, creates the class structure.

Not that indeed. Analysis includes very in depth discussion between the client and the person who is in charge of the project (business analyst, project manager), discussion based on which all the client’s ideas are detailed throughout the smallest aspects, so that the company, but above all the client himself is faced to the impact that his ideas may have on the project. However, the reason of these discussions is not producing documentation within the highest detail degree; paradox as is may seam, the main reason is identifying all the project risks… Providing answers to questions that may appear later, answers that, if affirmative, would trigger the need of redesign.

This is, in fact, what analysis is all about. This is how a quality project should start off, diminishing the possibility of late Change Requests.

I do not, however, support the idea that documentation is “the word of the law” and what the documentation says should be completed exactly, no questions asked. And that is because change or new ideas can arise from amongst developers too, not only clients. But a line should be drawn very clearly from the beginning. And if the whole process starts with the idea quoted above, I do not foresee a very happy ending…

Presumption is the mother of all f***ups...

This is a series of ideas that came into my mind when studying the management methodologies. By critique or eulogize, I do not mean to take sides and find a methodology above all. What I am trying to do is seek for a pattern that will suit my projects, my team, my management skills and, above all, my beliefs.

Iata o serie de episoade pe tema "Women In Technology". Nu le comentez inca... :) trebuie sa le vad pe toate mai intai :D

http://channel9.msdn.com/Shows/WM_IN 

http://www.cmdcorp.com

http://www.businessengine.com

http://www.hyperthot.com/pm_sdm.htm

http://agilemanifesto.org/

http://atlas.asp.net/quickstart/default.aspx

http://www.nikhilk.net/

http://beta.asp.net