There is one overall difference between this first SharePoint project and other web development projects your team has delivered in the past, the Software Development Life Cycle (SDLC) process. It's a real doozy the first time around and you'll want your team to learn these important bedrock technical concepts sooner rather than later.

The SDLC process for SharePoint isn't hard to understand and fundamentally follows good practices. Individual developers/consultants do their work on their development machine, then they deploy their solution to an integration server (where all of the different developers' work is merged) and then to a QA/Test environment where end users test the solution. Eventually, that approved solution is moved to production. The good news is that SharePoint provides excellent support for this process; however, the devil is in the details with testing in a production environment.

If this was a development project SharePoint defines and provides a "solution and feature framework". This framework defines the notion of a "solution", which is similar to a .zip file. Developers create these WSP files and deploy them to a SharePoint environment via a command-line tool. WSP files themselves include multiple different components called features. A feature is a cohesive unit of business functionality that could include some or all of the following SharePoint deployment components:

It takes some time to learn how to craft the various XML files that correctly define SharePoint features and the first time around, it can be daunting. This is especially true when it comes to updating an existing solution. However, it's a skill well worth learning and should be integrated with your project schedule.

By understanding the value of SharePoint's deployment capabilities the projects delivery process can be accelerated exponentially. But this knowledge is not normally in the realms of a straight .NET developer with no SharePoint experience.

So a question in the questions stage should include:

One of the things that distinguish SharePoint from other technology development is SharePoint's unique ability to prototype solutions for end users. You should take advantage of this capability early and often.

This is huge because of the school of thought where the business analyst documents the requirements, then the users sign off process or technology with which they are not familiar. The authors have experienced this sometimes when a company first installs SharePoint and starts an over-ambitious project and insists the business signs off on the requirements in the planning phase, only for the users to express that they really want something different.

IT leadership usually hears the business users' complaints and reacts by trying to "nail down" the requirements even harder by more rigorous and complicated methodologies changes. More meetings, more documents, and especially signoff contracts to force the user to agree on what will be done are an attempt to deflect any finger pointing later on. The result is normally a low-value solution and a poorly viewed first SharePoint project.

SharePoint-based prototyping only goes so far, of course. You may want to create some functionality that doesn't have a good analog in SharePoint today. In these cases, use prototyping tools. Balsamiq is one such tool and is very popular in the SharePoint community.

For further information:

These are low/medium/expensive options in that order.

These prototyping tools in the hands of a SharePoint Subject Matter Expert (SME) substantially improve the quality of your user requirements gathering process and reduce the risk of setting incorrect expectations with your end user partners. The next section, What's the best way to execute? dives more deeply into this last point.

The following screenshot illustrates the Balsamiq user interface and how a screen can be drafted to provide a user page layout: