How to deliver your project - Preparation

anthonywoods

Junior Member
I recently wrote an article to deliver projects, I hope this helps people who are not aware of how they should deliver and interact with their clients, but also give the more experienced users a bit more knowledge in the career field and what may be required.



howtodeliver.jpg



A Lot of developers and designers have their own unique way of delivering projects, some may not have any at all. I have conducted a real in-depth specification and explanation of how a project should be delivered with a client. I am hoping this bundle can be used as a frame-work for any beginning or even experienced users both in the studying and working field. Each stage will be delivered separately and over the course of the next coming weeks, and will contain information and useful tips linked to the stage topic.

Stage 1: Preparation & Client observation
Stage 2: Obtaining a structured client requirements document
Stage 3: Breaking requirements into tasks, deliverable and milestones
Stage 4: How to monitor your project during development
Stage 5: Key flaws that turn projects into failure
Stage 6: Client Interaction during project time
Stage 7: Testing & Bug fixing
Stage 8: Evaluating
Stage 9: Self Critical Analysis
Stage 10: Project Delivery
trans.gif


Planning and Client observation


Not everyone knows that planning is probably one of the most crucial aspects during a project. You tend to get a lot of developers and designers just briefly asking a client online what they require for their own unique project and then when they have the credentials they just get started right on the development. I cannot stress enough how wrong this can be, and thus this article will show how planning and client observation can play a big part in the development of the overall project.

"The Client. This simple phrase can turn some people's insides to jelly. Their knees begin to shake, and they start to get cold sweats. To some, it feels like the nice warm safety blanket has just been ripped away from them and now they are completely exposed. Client interactions can be nerve wracking, but it doesn't have to be so. In fact, you should look at it this way: every client experience is a new chance to further strengthen your relationship with the client."
From Ezube @rticles

Instead of talking to the client regarding the project via online e-mail or a social networking solution, it is always best to have face-to-face client interaction. When meeting with a client face-to-face, please do not dive directly into project discussion, get to know your client before any proceedings about a possible project takes place. Why must you do this? By observing and getting to know your client, you will not only find out how serious they are about the possible project, but your will also get to know a bit of the personality attached to the project that can only help with the overall quality. By getting to know the client, you are making the client feel more secure and confident which will play a big factor in the later stages of acceptance. Whatever you do, do not go into a meeting and make the client feel as if they are being interviewed during the meeting and that's all they are there for, this may be our goal but by implementing the above, you will not only benefit with the partnership, but with the overall quality of the project.

Remember to give your own perspective input to the client when receiving project brief from the client, ask questions that you MUST know in order to complete the project. You are the most experienced in the field, that is why the client has hired you, so if you have any doubts about any specifics of a project then you must detail this to your client and give possible solutions because if you fail to do this and continue, this will later on pay during the development which may not only cost money resources, but also time resources. It is your duty to help guide the direction of the project from the original idea of the client, without professional guidance from the developer or designer then the project may not be on a fully structured basis as the client was wishing which may result in poor quality.

Do not be scared to say no! That is a rule that I have personally followed when dealing with clients. Us developers and designers can be too nice for our liking and just agree with what the client is seeking, ofcourse it is the clients end choice but ultimately we should not need to go through a specific area or problem that we are not happy with hence we say NO if necessary. What happens if we just agree when deep down inside, we are not happy and haven't voiced our opinions? You will run into two outcomes, you will either complete a project that you are very unhappy with, or run into problems that you knew you may have or could have fixed or prevented if you just said no.

The Approach

Now that you have had a on-going conversation with your client the next step is for you to state how you will be approaching the project. What do i mean by the approach? Every project must have a valid approach and life cycle model for processing a project. Without an approach, you will look kind of stupid in-front of the client. If you do not prepare yourself with possible life cycle solutions before the meeting then you haven't properly prepared. Life cycle models are ways that you can execute projects, you may have heard of the famous Waterfall Life Cycle model? Below is an illustration of the waterfall life cycle and it's elements of process.

waterfall.gif


There is many more life cycles from V-Process, Incremental, Prototyping etc but I do not want to dive into this subject to deeply as I have an article that will go into more depth on how to choose the appropiate life cycles for specific kinds of projects. So yes, an approach to the project is crucial and gives the client a sense of feeling that you know how to execute projects efficiently and successfully.

I've always remembered the approach chat-up line a friend told me "Do not ever approach a women standing at your local bar unless you are prepared". In a sense, this applies to our client directly. When we tell our client the approach, they are obviously going to have questions about your choice so you therefore need to be prepared to not only answer these questions, but to talk the client thoroughly through the stages. Give them a brief weekly plan and which week each stage will be delivered. Make sure you have a deliverable and milestone by the end of each stage of your chosen life cycle approach model. What do i mean by deliverable and milestone? A deliverable is something that will be delivered at the end of a specific stage for example, the analysis document that should be completed in your planning stage, this will then be delivered to the client. A milestone is something that has been agreed or accepted. So therefore, the client must accept the analysis plan before proceeding to the next stage. This ensures that the client is a happy camper by the end of each stage, and that you are doing your job right.

Money Quote

I have seen this time and time again and the pitfalls it causes with developers and designers. Lets be honest, clients with no hesitation ask for a quote right up front. And many developers and designers are stupid enough to give them a direct quote back. Now that is insane, first of all from past experiences, when giving a direct quote back to the client upon request often scares clients away. No, its not my prices, it's just the thought of the money being in the primary discussion before any talks about a project has even began.

So what should you do? Well, don't give quotes directly to the client before actually talking to them. When having a meeting with the client, try and dodge the quote question at first until you have further knowledge regarding the project. How do i do that? Well, when a client requests a quick quote, just simply reply "Sorry, I do not have enough information regarding the project and requirements for me to quote a good and precise price, you need to tell me more". Now your probably thinking I'm dragging on the meeting and not answering the clients direct question, but to your advantage, the longer the meeting is held, the more confident that you will get a paid project. Clients tend to stay with their hired developers and designers if they feel comfortable, and by dodging that quote question for the first time, you are back in the planning zone with the client. The more information you give about what you can do for the client and there project, the client becomes more excited and therefore that quote question near the end of the meeting will not be a hard task to ask and answer. When you finally get to quoting a valid price, make sure you are confident in your stating price and do not let the client change your mind.

What is next?

Now that you have had a brief meeting with the client which you should have prepared and observed, this now sets up the next task for another meeting. You do not want to over kill the client with a long length meeting for the first time so it is valuable to break meetings into a short length so the information being discussed is easily remembered. Your next meeting will be discussing the clients requirements in full detail and the construction of the analysis document which you should then present to the client to sign off before any major project out-line plan is structured.
 
Wow - excellent post Anthony!

Its amazing, from my experiances how many people have no system at all in place!
 
I totally agree Mike, if you want to seperate yourself from being a normal designer / developer to a fully structured one which is on the verge of making it into real time free-lancing or employment, then i would highly suggest that you must have an appropiate and efficient way of not only dealing with clients, but delivering projects and you must stick to what you know.

I am intrigued to know what are the users input of how thy deal with thir own priorities during projects :) so please do share
 
Great article - I often find that with some clients you almost have to show them how to create a brief. The ones that demand a quote for work without meetings & preparation I almost always pass over.
 
Back
Top