Throughout my projects, every time I was required to make a decision, I asked myself the question, do I get input from the team first, or do I make the decision and then enforce it without prior team input.  Each approach has its benefits and over the years, I have found that getting input from team members builds cohesiveness amongst team members.  The Collaborative Approach makes team members feel they are part of the team, and are important to the team.  Once the decision is made in a collaborative environment, it is more likely that team members will implement/follow the decision.  The team stays focused on the goal at hand.  A big part of the success of my current project had to do with listening to the team’s input.

Building a system is a complex task, somewhat like building a bridge.  It is unfair to ask a user of a bridge (drivers and pedestrians) to design what a bridge would look like.  Likewise, it is not prudent to ask users of a system to design what a system’s UI would look like.  We’ve all driven and walked across bridges, but unless we are civil engineers, we wouldn’t know what structural specifications are required to build a bridge.  It is also the case that system users cannot always visualize what they want, until they see what it will look like.  Many “theorists” in the requirements management world write extensively about requirements documentation via use cases and such.   It is important to have requirements documented.  It is equally important to have UI mock-up’s that have been “test-driven” by the system’s user community.  Ideally, the mock-up’s should be “working” UI’s.  That is, the users should be able to click links, buttons, etc. and see the outcome, such as confirmation pages.  Bottom line, requirements should never be baselined without UI mock-ups being baselined as well.

Software developers have a tendency to underestimate the time required to complete Change Request tasks. Most developers only estimate the time it might take to make the code change itself. For more reliable estimates, the following items should also be taken into consideration:

• Estimate for Requirements gathering, elaborations, and documentation (requirements elaborations included back-and-forth emails and meetings that at times took a significant time)
• Estimate for Updating Design and Software Architecture documents
• Estimate for database changes, if any