From experience, it seems that many organisations do not realise how important the start of the project really is!  They do not seem keen to spend that extra bit of effort upfront, and end up having to spend considerably more (both in terms of effort and cost) when the project deadlines start approaching.  And not only that – in such cases, most of the time is spent fire-fighting, rather than concentrating on constructive tasks that will improve the quality and lead to enhancements of the final product.  No one likes to spend project time and money by fixing up the defects that were introduced by poor planning and lack of thoughtfulness, under constant stress, doing long hours, and running around like headless chooks!  The stressful environment of such projects leads to further bugs being introduced (due to excessive hours and stress), which in turn leads to more problems – a vicious cycle it is.  In such an unfortunate situations, cool heads need to prevail, and emotions should not be making the decisions.  Needless to say, such projects generally do not end up meeting users’ expectations. 

We believe that it doesn’t have to be this way.  Spending the extra effort at the beginning of the project can set you onto the right path, and will help you identify most of the issues that can cause potential problems later on. 
Starting a project can be compared to setting the right foundations when building a house.  No matter how good the craftsmanship is, no matter how good the materials are, no matter how much time is spent building it – if the house is built on the wrong foundation to begin with, sooner or later, something will make it crumble!  However, if the house is built on the proper foundation, even the occasional mistakes by the builders will not cause the entire house to collapse.  Such building defects generally have a limited effect, and are easier to fix. 

We think it is imperative that the entire project team spends the extra effort at the start of the project, not just the Project Management team.  Technical Infrastructure teams, Development teams, Functional teams, Change Management teams, etc … each project team member should be thinking what can be done to ensure their team and themselves can be as efficient as possible, and how they can contribute in making this project a success.  All of the great ideas should be communicated to the rest of the team.  There should be constant communication between different teams, and between members within a team, throughout the project lifecycle.  Communication was, and always will be, a great part of the foundation of any project.  Open-ended, regular and efficient communication is the key part of every successful project. 

So how can this work in practice?  Let’s take the development team as an example.  The team members could come up with the following (NOTE: this is by no means an exhaustive list):

Development approach

Meeting schedule & structure

Monitoring & communication mechanisms - there needs to be some monitoring in place to keep track of the development efforts, adherence to standards, etc.  This should be determined at an early stage of the project - otherwise, things could get out of hand, and chances are it will be hard to correct at a later point. 

Development schedule - it is helpful to determine what modules to develop first.  Some of these modules could be quite complicated or unknown, and could have an impact on the overall project plan.  Developing these first could help manage risk, and it can also help gather knowledge for the team.  The knowledge gained from that exercise could in turn be shared and used to speed up the development effort (especially if there are other modules that are similar in nature). 

Development standards & guidelines - setting the standards & guidelines early can not only improve the quality of the software, but it can also speed up the development effort considerably.  The development standards and guidelines should be created based upon the input of the entire development team.  As such, the documents can also be used to transfer knowledge among developers.  The standards can be re-fined throughout the project lifecycle - however, if most of them are set at the start of the project, it could save quite of a bit of headache down the track. 

Look and feel standards - whether they are incorporated as part of the development standards or a separate document, having these set early can make the whole system look consistent and professional.  Otherwise, trying to change the system to conform to a certain look and feel standards at the later stage of the project can be quite a time-consuming task. 

Setting distinct roles and responsibilities - having distinct roles and responsibilities makes the developers feel valuable, and it gives them a clear idea of what’s expected of them.  It can also serve as a good motivation tool, since each developer would strive to fulfil their responsibilities.  Having clear responsibilities defined early will also help avoid potential problems in the future, by reducing duplication of effort and aiding standardisation. 

How-to documents - further tool for knowledge transfer.  They can be used in conjunction with the development standards & guidelines. 

List of 3rd party tools, alongside with instruction on how to use them - these tools can speed up, as well as ease and enhance the development effort.  They can be used in conjunction with the development standards & guidelines.  The earlier they are in use, the more time is saved.  For example, in a project where there is plenty of SQR development, SQR Runner may turn out to be quite useful. 

Documentation templates (design templates, test templates, etc)

Development checklists - these can help with adhering to standards.  The earlier they are in use, the more standardised the system should be. 

Development handbook - this handbook could be given to each developer on the project, to let them know of their roles & responsibilities, standards, documentation, index to , etc.  This can be handy to get the developers off to a flying start. 

Commonly used queries

Common function libraries/Application Packages - having commonly used functions and methods structure set up aids in consistency of the entire system and promotes re-use, which in turn cuts down on the development (as well as debugging) efforts.  It is much easier to change a piece of code in one place, then it is to change it in 50 places! 

Creation of navigation collections - creating these early can help developers navigate more easily and efficiently through a PeopleSoft site, thus speeding up the development effort.  The earlier they are in use, the more time they save. 

Etc (could go on for a while - whatever will make the development effort more efficient and effective)

The ideas generated by the development team could then be communicated with the other teams in the project.  These ideas may turn out to be helpful to other teams, or these teams themselves may have some feedback, or ideas of their own that will in turn help the development team.  For example, the development approach may dictate what new environments will need to be created.  This could be communicated with the Technical Infrastructure team, and they may have additional ideas about the environment schematic.  Functional team could be consulted for Look and Feel standards, and so on. 

Having the right project foundation set will instil confidence into the project team early into the project lifecycle.  Involving the project team in this process will also help them gain further confidence in the project and arouse enthusiasm.  Furthermore, it will assist in building the project team, as each team member will feel valuable and important, and thus be more willing to contribute to the overall success of the project. 

Of course, no matter how good your project start-up is, it will never be perfect.  Things will be missed out; mistakes will be made, or some unforseen situation may force a change in project plans.  However, once the project is set on the right foundations, the team will be ready to efficiently tackle any problems that may arise.