What are often overlooked steps to take before beginning a big project

Question

Obvious steps that are easily overlooked or great tricks that you have learned to implement that make things come together smoother. Or even ways of doing brainstorming or mapping that have really help

Answer 1

Making sure that the LAST project is finished up.

Answer 2

A lot of big projects don't take testability into account at the very beginning. If you can automate your use cases from the start the project will have a good chance of being done with minimal defects and requirements issues.

Answer 3

A few things come to mind:

Break things into manageable chunks. This seems like an obvious step, but I've worked on a couple of large projects where this wasn't done or wasn't done well.

Make sure you have some domain knowledge prior to trying to estimate. One project I worked on required a significant amount of domain knowledge that we didn't have at project start, but they wanted us to estimate the unknown... which is a fun exercise in futility.

Make sure the customer is involved in your project planning. The reality of life is that those requirements are going to change. Everyone needs to know that and know that all changes affect the schedule and that big ones can ripple through the entire project. It is best to keep those line of communication open so there are no surprises.

I like to do things in an agile manner - short iteration cycles, test-first, and a known set of items that will be in each iteration, adjusted by the team as need be. Consider this approach when planning your project.

Don't make testing an afterthought. It can be VERY useful in making sure your assumptions are correct and your implementation supports your assumptions.

I'm sure there are lots of other good ideas.

Answer 4

Don't make the stupid mistake of dooming the project before it starts: make a good estimation.

• Read Steve McConnell's Software Estimation: Demystifying the Black Art

• Make sure you have metrics from your past projects on planned time vs actual time for different types of activities. If you don't have them, start gathering them in this project for your next project. You can only make realistic estimates based on past performance. If you have never done something similar in a previous project and have metrics about how long it took then you are not estimating, you are guessing.

• Devote at least a week to design your software architecture: You cannot make an estimate if you don't know what you are going to build. Designing your architecture gives you a first view on what you have to build.

• Don't devote a lot of time making a detailed Microsoft Project plan for the whole project. I can guarantee that before 3 days it is already obsolete and impossible to change (thanks to MS Project).

Answer 5

Here's one:

Start with a build script and continuous integration server from day 1.

It's very easy to create when you have little to build... add on to it as you go.

Answer 6

Developing a project plan is probably the most often over looked step. I don't mean a MS Project schedule, but a plan covering scope, schedule, cost, quality, HR, communications, risk and procurement management.

One small part of this i often see people mess up is the identifying who your stakeholders are. Who can influence your project? Who can help? who is your project going to affect? who are your users and customers?

Identifying Stakeholders is a crucial step that should be done before you start to make your plan. It's important in simple projects such as upgrading an network (eg: make sure payroll is happy with this risk of the network being down for 24 hours during a payrun) to complicated finance system roll outs (eg: make sure that your infrastructure people are involved so that they can assess possible impact on the network, make sure you include the business acquisition people to assess any near term needs such as your system having to handle Indonesian VAT legislation)

So simply make a list of all these people at the start and make sure they are communicated with. At a minimum keep them up to date on what is happening on a regular basis.

There's whole methodologies for these sorts of things, but identifying your stakeholders then creating a plan covering the above 8 areas in sufficient detail is a good step.

Answer 7

Make sure you identify and communicate with the major stakeholders. Nothing will ruin a project faster than a stakeholder who feels they are out of the loop, or doesn't understand what you are trying to accomplish and how their assistance/network/help/expertise/etc is needed at each step.

Make certain everyone knows that you will be holding a project post-mortem so everyone can learn from their mistakes - remind them throughout the project and schedule it. This isn't just a wrap up, but an opportunity to improve without pointing fingers.

Always, always, always, always follow up, and follow up your follow ups with, "Did I cover everything?" The people you talk to have a lot of knowledge which they won't think to give you unless you stimulate them a little bit. Often (too often!) they will assume you know something, to the detriment of the project.

Answer 8

Good points on here. Here are are few additional ideas:

• High-level purpose. Clients love to jump into details. Everyone's an expert, so you've got to manage their input channels. Get them talking about the project and their expectations before you talk about which lightbox to use.
• The value of client involvement. Hunkering down and creating a few workflows w/the client present is completely tedious and invaluable.
• define an endpoint. Where does the work end? Is there a handover procedure/doc? Are you making an application for them, or are you working until the client says 'OK, I'm sick of you.' This isn't critical, but is often missed.

Answer 9

Make sure you really need a big project - aka control the scope.

Answer 10

1. Focus on good robust design.
2. Testing efforts
3. Changing requirements

Answer 11

Make sure:

• You understand the purpose of the project.
• That there is a business case for the project.
• That the project has a sufficiently infulential sponsor.
• That sufficient resources likely to be available to the project (finances, people, time).

Answer 12

Make sure you aren't implementing something that hasn't already been done somewhere else, and is a feasible alternative.