I have worked on a large number of projects in my software development career. The team sizes have been between one and about fifty. There is one thing common to most projects. In the beginning, most of them are over engineered.
During the beginning of a project, people are generally very gung-ho about the project. Right from the project manager to the developer to the tester, everyone is very excited to be on the project. So, every minute detail is discussed to death. Discussions are held with every single member on the team whether the database column to store the id of a product should be varchar(32) or char(32).
Towards the end of the project, it is usually about getting the damn id into the database and wondering why the id is not being retrieved at all, never mind the data type!
I had a terrible sense of deja vu recently when at my office we starting discussing a new project. The kind of detail we went into was mind numbing. I couldn't help but shake my head thinking about the futility of it all. A few more days and anyway everything would change. Why bother then?
In new projects, I strongly believe, we should always go about things in a top-down manner. Look at the big picture. What is the problem we are trying to solve? What are the pain points that are being addressed? Then get down to the rest of the stuff.
Often engineering teams spend hours trying to solve problems that the customer couldn't care about. I have seen this all too often. That is where the Project Manager must step in. She must never lose sight of the 'big picture' - what exactly is the problem we are trying to solve? Every decision taken in the project must keep this in mind.
That way, a lot of unnecessary effort and heartburn can be avoided in most projects.
During the beginning of a project, people are generally very gung-ho about the project. Right from the project manager to the developer to the tester, everyone is very excited to be on the project. So, every minute detail is discussed to death. Discussions are held with every single member on the team whether the database column to store the id of a product should be varchar(32) or char(32).
Towards the end of the project, it is usually about getting the damn id into the database and wondering why the id is not being retrieved at all, never mind the data type!
I had a terrible sense of deja vu recently when at my office we starting discussing a new project. The kind of detail we went into was mind numbing. I couldn't help but shake my head thinking about the futility of it all. A few more days and anyway everything would change. Why bother then?
In new projects, I strongly believe, we should always go about things in a top-down manner. Look at the big picture. What is the problem we are trying to solve? What are the pain points that are being addressed? Then get down to the rest of the stuff.
Often engineering teams spend hours trying to solve problems that the customer couldn't care about. I have seen this all too often. That is where the Project Manager must step in. She must never lose sight of the 'big picture' - what exactly is the problem we are trying to solve? Every decision taken in the project must keep this in mind.
That way, a lot of unnecessary effort and heartburn can be avoided in most projects.
Comments
this is a lesson and good case study for technical architects!
BTW, is your project manager 'she'?