How to Run a Successful IT Development Practice

Jan 16, 2013 10:42 AM, - Posted by Tommy Segoro

INTRODUCTION

In this article I want to talk about running a successful development practice. I will list the tools and automation that you can use to ensure that your development practice runs smoothly.

THE TOOLS

The tools we need are:

Development environment, testing environment, UAT environment and production environment. If possible ALL environments are configured with the same spec and settings. Otherwise, the least you have to do is UAT and Prod are configured with exactly the same spec and settings.

Development environment is where the developer does the work. This environment should be personal to the developer. Why? Because when a developer needs to perform a server restart or SQL service restart, debugging, etc it will not affect other developers.

Testing environment is where alpha testing (ie. internal testing) takes place. If you have multiple developers working on a project, you will need to check-in the code and test the integrated code. This is the environment to do it.

UAT environment is where user/client testing takes place. Once the alpha testing passed, the code is now ready to be deployed for UAT testing. This is the environment to do it.

Production environment is the LIVE environment where the application is used by the entire client organisation.

Why – ideally – do we need to configure all environments to have the same spec and settings? This is to eliminate any risks of the code works in one environment but not the other. I know though that this is probably too much to ask since resources ain’t cheap. Therefore, if you can’t configure all environments to have the same spec and settings, at least UAT and Prod are configured the same. This way, if the application passes UAT, it will also pass Production.

When I say “configured exactly the same”, I literally mean “configured exactly the same”. Meaning, the topology has to mimic (eg. if Prod has 1 server in DMZ, 1 server internal and 1 DB server, the UAT needs to be the same). Any third party applications that you may install need to be of exactly the same version. Don’t install V1.0 in UAT then V2.0 in Prod otherwise you are introducing a risk.

Source control application

This is what has always been missing in most of my clients’ organisations especially if they are not an IT consulting organisation. You HAVE TO HAVE a source control application where you can version, check-in/out your code into. Otherwise, you may risk yourselves of losing your source code.

The source control app I often use are Microsoft Team Foundation Server, Microsoft Visual SourceSafe and SVN Server. There must be others but as I work mostly with Microsoft technologies, the above are the ones I normally use.

The source control application you use needs to have the ability of check-in, check-out, versioning, labeling, branching and merging. You need to be able to identify which version of code is currently deployed in which environment. If your source control application is not supporting these functionalities, you better find another one.

Development IDE (Integrated Development Environment)

Do you have a proper IDE such as Visual Studio? There are many others such as Sun One, etc but the ones you’re looking for are the ones that can debug your code and also provide you with good text-editing functionalities. The good one can also label different part of the code with different color which makes it easier to read.

I used to develop HTML in Notepad but not anymore. It’s all black-and-white which makes it harder to read. Ensure you have a good IDE so that you can work efficiently.

Task and bug tracking application

You need to use task and bug tracking application. This way everyday you can always track how your application is performing and also everyone in the team knows that he/she needs to do.

I use Team Foundation Server and Team System Web Access mostly as it allows me to assign task and report bugs easily. There are a lot of open-source ones that you can download for free.

Common methodology and best practices

Do you follow a development methodology such as Agile Development Methodology? It is good to follow a particular methodology because it helps you keeping things in order.

How about MVC, MVP, design patterns? Do you follow any of these?

I also often use Microsoft Enterprise Library for all my “standard ground work” such as logging, encryption, etc. Do you have a common library that you use for development?

When everyone in the team uses the same standard, although the way they code may look different, but at least your application is a lot more manageable.

Deployment process and procedure

When it comes to deploying your code, do you have a standard deployment process and procedure? This is useful to avoid “cowboy”-style deployment where your developers can just deploy whenever they like.

Some of my procedure is:
– Deployment Change Request document needs to be created and signed off by the client
– All deployment to UAT and Prod need to be done after hours and only on Tuesday and Thursday or any hour on the weekend (Saturday and Sunday);
– Deployment to UAT and Prod needs to be communicated to the business at least 24 hours prior to the actual deployment;

Timesheet application

Do you run a timesheet application? A lot of my clients are using paper-based timesheet. Nowadays there are a lot of web-timesheet application that you can utilise. This is important to track budget.

A paper-based timesheet will create more overhead than anything because you then have to re-import all the hours to a separate spreadsheet, etc.

Ticketing and support application

You may also need a ticketing application especially if you are running a help-desk practice. This application allows you to track all phone-calls or support requests and attend to them appropriately.

Do NOT let the employees of your client’s organisation to talk directly to your team members. Always force them to use the ticketing application. This way you can assign tasks to your team members in a more manageable way.

Shared directory

Do you have a shared directory where all your downloaded applications are located? This is useful so that your team members don’t have to keep downloading applications that may have been downloaded previously.

I also use it to share movies and other interesting documents 🙂

Project documents storage (ie. document management system)

I use something like SharePoint to store and share the project documents. Use a similar system so that your team members can always refer to these documents (eg. Business Requirements, etc) anytime without bothering you.

THE RESOURCES

All in all a successful development practice depends on the resources themselves ie. the developers and you as the manager. Look for someone who is easy to work with and not the one who always wants to do things his own way.

The pitfall is normally: the smarter and more experienced someone is, the harder to work with. Therefore, during the interview ensure that the person can work with your methodologies and procedures.

Do things that can tighten the bond within the team such as Friday lunch or daily coffee break. It is very important to keep the morale high. You can also send jokes around.

Get everyone in the team to present something interesting once a month or once a week eg. new technologies, etc.

CONCLUSION

Running a development practice should not be that hard but you have to have the right tools and methodologies.

Feel free to add more items in this list.

Requirements Gathering: Asking the Right Questions

Jan 16, 2013 8:36 AM, - Posted by Tommy Segoro

INTRODUCTION

I’ve talked a lot about starting a project with gathering requirements. In fact, in my series: How to Deliver a Successful Project, gathering requirements is THE key to a successful project. The problem that I’ve often experienced though, the requirements gathering session itself can turn into a boring, going-around-the-circle sort of session. In this article I would like to share with you few tips that can help you executing an efficient, straight-to-the-point requirements gathering session which in the end resulting in an understanding which you can then map to a Business Requirements document.

Now, imagine a scenario. A client (let’s say the name is ABC) just called you because they have heard about your company and how your company has delivered an excellent work for an another client which happened to be ABC’s supplier. ABC is now interested in talking to you for a new solution to the problem/inefficiency that they are currently facing. You and them set up a time to meet and here it was, you and their IT manager sat together to discuss about what it is that ABC is looking for.

So here are few tips that I normally take during a requirements gathering:

Don’t start by jumping straight into the questions about work

There is always a temptation of jumping straight into asking about the work itself. But I’ve learnt that this is a great opportunity to build a relationship with the client. I always start with, “Well, how’s things? What’s your role in the company? How long have you been here?, etc”. The key is to be a good listener. You’ll never know if he/she is currently under pressure and needs someone who can listen?

Ask about the goal of the engagement

Then ask about the end game ie. the goal of the engagement. My question is something like, “What is it that I can help you with?”. This will guide him to tell you what sort of solution they will need. The answer is normally something like, “Well, we need a website” or “We need a portal to share documents”, etc.

Be a good listener, stick to the point 

There is always a temptation of pouring into your client of what you know eg. “Oh if you need a portal then we’ll have the latest news on the homepage, then rotating banner, then this and that”. From my experience, the requirements gathering session is all about the client and not you.

You may argue that by introducing all these extra functionalities, they may help the client. But my question to you is, is that really what they want though? If we are not careful, the session can turn into an going-around-the-circle thing because you are moving the goal post further away. Stick to the point, that is: “what the client wants”.

What if the client doesn’t know exactly what they want? Well from my experience, unless he/she is crazy, he wouldn’t say to you, “You know what…I just want you to come in and meet with us. We still don’t know yet what we are going to talk about but just come in first and talk”. It’s just crazy to invite a consultant to meet and yet being totally blank. When someone invites me in 100% of the time they already know what they want. They just often don’t know how to get there.

My requirements gathering session never goes over 1 hour. Any meeting that goes more than 1 hour will turn into a boring meeting.

Talk about your solution and what it requires and ask what the client can provide

For example, if the answer is, “We need a website”, then your next question is, “Ah, we have a CMS solution that allows you to update content, upload images images, etc yourself”. But I then need to discuss with you the sitemap of the site. What about the branding and design? Have you got it? Also, do you have an environment to support ie. the web server and the database server? How about hosting? etc etc.

If they can’t provide you with answers that can satisfy your solution’s requirements (eg. sitemap for website, metadata for SharePoint, etc) then you unfortunately have to go back on an another day to discuss about it. Give them few questions to take home which you need the answers for.

The key is to keep following up with the client. Make your client feel as if you are prioritising their need. Follow them up in few days time and don’t leave them in limbo.

Fill in the gap

You are the expert who knows about the solution you are offering and you know what is required to make sure that the application is running correctly. Therefore, you then need to fill in the gap. For example, if the client says, “Well we haven’t got any server to host SharePoint”. Then your next statement will be, “So we’ll need a SharePoint Server to be setup. We can assist you with that. We have an industry best practice guidance that we normally follow”.

Confirm scope and deliverables

Now that you have understood what is required and what is missing (ie. the gap), you can now confirm the scope. At this point I would normally say something like, “OK so what I’ve got so far, you need a website but you also haven’t had the environment to host it on. So what we need to do first is to configure the environment.”

“What I normally suggest is to build a UAT and Production environment so that if there are changes that need to be made to the Production environment, they can first be tested. So, based on this I will divide the engagement into 2 phases: The first one is the configuration of the environments and the second is the actual work of building the website itself. Is that OK?”.

“So I’m going to get back to my office now and document all these in a Business Requirements document and a Proposal (that contains the effort required ie. how long it’s going to take) then I’ll submit to you for review. The engagement starts when you sign that document. Is that OK?”.

A lot of the times, at this point, the client will ask, “So how long is it going to take roughly?”. Your answer should be, “Well, again I need to analyse all these in details and get back to you with a proper quote. But if you ask for a ballpark, it is going to be about at least 80 hours worth of work”.

It has always been my principal to NEVER promise any dates or effort unless I am sure of it. That word “at least” indicates that the estimate may and will change. The very last thing you want is for the client to take your word for it and write down what you said. Now that he’s got a record, you will be in trouble. That is why I never promise any exact dates or effort during this session!

What I can promise however is the date when I’m going to get back to them with the Business Requirements and Proposal document.

Draw business requirements and proposal and get back to the client timely

Now that I have already got all the information I can go back to my office start developing Business Requirements and Proposal document.

Download the template for FREE!

Make sure you deliver these documents by the  promised date. I have been in an IT consulting company before where the director was always late (sometimes by a month) in returning these documents. This will only make you look unprofessional and not prioritising the client.

CONCLUSION

A requirements gathering session should not be difficult as long as you ask the right questions. It should never go for more than an hour.

How to Deliver a Successful Project – Part 7 – Project Closure

Jan 12, 2013 2:36 PM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

PROJECT CLOSURE

First of all, as part of this article: DOWNLOAD Project Closure Document Template FOR FREE!

Now that you have completed the project, make sure it’s closed properly. I’ve been in many instances when a project is never closed properly so it’s kind of hanging there. You don’t know what state it is in, yes the application has been deployed but…..

So make sure you close the project formally.

Use a project closure document and get the client to sign it off to formally complete a project. The document should mention about all deliverables that need to be delivered and a checkbox next to each.

Have a formal meeting to close off a project. Organise a catering if necessary just to make it more professional.

Take your team members for a free lunch treat.

And finally do a final meeting with your team members to determine any feedback and improvements that can be done moving forward.

CONCLUSION

As simple as it may sound, project closure is very important. It shows a sign of achievements. It puts smile on your face, on your team members face and obviously the stakeholders’ face.

How to Deliver a Successful Project – Part 6 – Managing Changes

Jan 12, 2013 2:27 PM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

MANAGING CHANGES

First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE! Use it to produce variations and change requests document.

Changes always exist. It is almost impossible not to cater for changes in any project. Changes are good because most of the times changes make things better. In fact, I’ve heard of this wonderful quote:

A change may not make things better, but if you want to make things better there has to be a change.

So all changes need to be catered for and managed properly because otherwise, they will eat up your project time.

What is a change and how do we identify it? My definition of a change is any action item requested by either the client or yourself that is outside the scope definition described in the Business Requirements document. For example: the scope is to deliver a login mechanism that accepts username and password. Suddenly the client said to me, “Oh actually Tommy…can you add first name and last name field for checking as well?”. This is a change.

If you said, “Yes, I can do it” without treating it as a variation because you think it’s a five-minute job, then you are at loss. It means that you do more effort for free ie. the project hours is not increased, the deadline is not moved back and yet you still do the change for them. And not only that, you are introducing a new risk. What if the what-you-think-as-a-five-minute-job suddenly becomes an 8-hour job because it’s more complicated than you expect?

Therefore my dear readers, all changes have to be properly managed.

How do I treat a change (ie. out-of-scope items)? First I need to identify the type of change requested. I divide it into 3 categories:

5-minute change

This one I simply document in an email and send to client for approval and I’ll just do it for free. It only takes 5 minutes which is nothing. You keep the client happy and yet you are not introducing any risk. Example: Changing link color or font size.

50-minute change

Again, this is like the “grey area”. If I have a 50-minute change I will normally just document it in an email, send to cltient for approval then do it. Example: Changing banner padding size or add an email validation to the username field.

500-minute change

Now, this is different! I will treat it as a separate project, totally new project called a variation project. What it means is, I have to make another Business Requirements document, a quote and proposal, a project plan and the whole “shebang”. All the documents need to be signed off, etc. This way you will have a dedicated allocated time to do this change.

500 minutes (assuming that it is an 8-hour/day engagement) = 1 day and 20 minutes. This is a lot! Can you move the deadline by 1 day and 20 minutes? Probably not. So treat this as a separate project.

Example: Adding a new field to the user profile table. It may sound simple but imagine how much code changes there are.

SCOPE-CREEP

We often hear about scope creep. What is scope creep? Scope creep is just one of those “great ideas” that your client suddenly has in his mind (imagine a picture of a light bulb above your client’s head). For example: “Oh you know what…I think if we add a survey on the right hand column of the Intranet that would look good”.

You as the project expert need to quickly identify the type of change it is. If it’s a 5-minute or 50-minute job then you can do it for free but if it takes longer then you have to raise a variation or change request.

Scope creep often happens at a random time. Out of nowhere your client may contact you because he has an enlightenment that a great feature needs to be developed. Again, identify how much effort it’s going to be.

From my experience a lot of the time the client has no idea how long a particular “great idea” may take to be developed. Therefore, he will rely on you to tell him how much time it takes to do the change. If you simply say, “Yes, sir we can do it” then he will take your word for it. So be careful!

SCOPE-SEEP

Now, we also have scope-seep. What is a scope-seep? Scope-seep is an unnecessary complication that YOU INTRODUCE. For example, in a meeting, you suddenly say, “OK guys we have developed the login screen. I have an opinion, I think if we do double-opt-in and activation prior to logging-in it would be very secure and great”.

Whenever you introduce a feature, trust me, your client will take your word for it and will assume that you will do it for free.

Again, it is always good to suggest things as the more changes they agree to, the more work you get. But you have to be extra careful to not introducing too much changes and in the end you are the one who is entangled by your own “great ideas”.

CONCLUSION

All in all, a change is good. For me I’m always open for a change. It also means new business for me. The more changes my client introduce, the more work I have – meaning the more income I get 🙂

However, you just want to make sure that you are not adding an unnecessary pressure for yourself and your team.

Those who don’t manage change properly are bound to fail.

How to Deliver a Successful Project – Part 5 – Delivery: Communication is Key

Jan 12, 2013 12:08 PM, - Posted by Tommy Segoro

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

DELIVERY: COMMUNICATION IS KEY

This is the part where we are in the process of delivering the project. In software development term: the coding time. From my experience to ensure a successful delivery, communication is key. What does communication mean? Communication means that everyone related to the project (ie. the stakeholders and team members) is up to date with the progress of the project.

Communication encompasses a lot of things:
– You and the stakeholders: use weekly progress report and weekly meeting to track project
– You and the team members: use weekly meeting and daily timesheet to track project
– Your team members: Use task list and source control application such as TFS or sub-version to communicate with each other
– Your team members and the stakeholders: Use bug tracking application
– Using email to summarise any verbal conversation that may have impact on the delivery of the project
etc

But what I’m saying is, communication is the essence of a successful project delivery. I have been in a lot of clients where communication is not clear. Again, I’m talking more than just a casual chat or daily coffee break between the team (ie. words conversation). I’m actually talking about processes and tools that you can utilise to ensure that everyone is up to date with the progress of the project.

The main goal of communication is:
– Everyone is up-to-date with the progress of the project;
– No single thing related to the project is overlooked and missed;
– No surprises arise (ie. “Oh I forgot to mention that I’m taking a 1-month annual leave next week”).

So let me break communication down into several categories.

You and the Stakeholders

Communication needs to be clear between you and the stakeholders. We want to make sure that the stakeholders know how the project is progressing. Therefore, if there are some issues or delays, you will not be in trouble. The best way to communicate with your stakeholders is through quick weekly progress meeting and weekly progress status report. Unless it’s a designated meeting for demo, do NOT demo anything otherwise you are creating a room for scope-creep. Your job is really just to report to them how the project is tracking and if everything is still on-track for the deadline.

The weekly progress report is also very handy. The progress report contains the following information:
– What has been achieved this week
– What is going to be achieved next week
– Any potential risks

You and the Team Members

Between you and the team members communication needs to be flowing. You need to know how everything is going with your team and recognise if there is a potential risk or delay. Do a quick weekly progress meeting with your team to see if everyone is on track and if there is any potential issue (eg. Developing JQuery script takes longer than expected, etc).

You can also follow a particular development methodology. Me personally, I use Agile development methodology but outcome-based instead of the one-or-two-weekly sprints. If you are not familiar with this methodology just look in Google there are tons of information about it.

Use technology if you can to communicate with your team such as bug tracking, task list, etc. I personally use Team Foundation Server (TFS) because in it there is already a built-in bug tracking, task list, etc.

I also often send jokes and buy my team members coffee just to lift the morale of the team. Remember, they are the ones doing the ground work so you need to make sure that everyone is top notch – as far as morale is concerned.

Between Your Team Members

If you are doing hands-on work yourself, use technology to communicate between yourselves. Again, source control repository such as TFS or SubVersion is very important to ensure that everyone is sharing the same code and no one works at the same file at the same time. It also helps maintaining the version and integrity of your code.

Make sure that you also have a shared folder for tools and software downloads so everyone in your team has the same tools installed and no one is left out.

Send jokes among you. It helps in keeping the morale high.

Your Team Members and the Stakeholders

Give your stakeholders access to your bug tracking system so that they can report bugs during UAT.

Give them some test cases so they know what to click and test.

NEVER allow the member of the stakeholders contacts the team member directly otherwise communication can be interrupted and things that are mentioned to your team member may never get exposed to you (hence introducing room for scope-creep).

If you want to give stakeholder member access to your team member, that is fine but you have to educate your team member to ALWAYS DOCUMENT the conversation in an email and CC you and the rest of the team members.

You, Team Members and Stakeholders

As mentioned above, ALWAYS document every verbal conversation that may affect the progress of the project. I’ve had one of my client’s stakeholders came to me and said, “Tommy I think it will be good if you change the color of the links to red”. Although it’s a 2-second job but if I didn’t document it and I changed it, then the rest of the stakeholder members didn’t like it and asked me to change it back to blue and I said to them, “But Bob told me to change it to red” and Bob said, “Sorry, I didn’t recall telling you that” then you’ll be in trouble.

Identify changes in the conversation then document it in an email.

You, Team Members, Stakeholders and the Rest of the Business

Once the software is ready for deployment, communicate with the rest of the business by letting them know ahead of the deadline that a new software is going to be implemented. It’s like on the road where I see a sign saying, “Next week the road will be closed for Iron Man event”.

By you communicating with the business ahead of time, you are also indirectly creating an anticipation. People in the business will be looking forward to use the software.

Use positive words in your communication such as: “We are going to roll out a new HR software next month. This software will allow you to work a lot more efficiently because you will be able to submit timesheet online”, etc.

CONCLUSION

There are tons of other things that you can do to ensure communication is flowing but if you can do the above at the very least, you are doing really-really well.

The project is only doomed to fail if conversation is not clear.