Project Managment

Working in a distributed team is becoming more and more popular. With the power of Internet, today we can easily work together without worrying about physically travelling to work. It saves time, fuel, and personal energy. Can anyone imagine anything better?

But, all the convenience comes with a price. Co-located workers have the advantage of direct communication, which is often underestimated. When you have all of your coworkers in a room, they will answer you immediately when you ask, “Is that document is ready?” or “Can our original design support these new requirement changes?”. When the team are distributed in many locations (and possibly many time zones), things are quite different. We must wait for our emails being answered, or the chat reply message, while the others are on their other tasks. We may get stuck and need help from another team member who are sleeping while we are at work. That’s not only irritating, but also become a real challenge for any distributed team want to push their productivity toward their maximum potential.

I have been in this position more than once. Some were school projects, some were start-ups with my friends, and some in my work elsewhere. Some of them failed desperately, the rest succeeded. What I learned from them is: the way we do things as a programmers have a big impact. And success is not only for the Project Manager – it’s something we programmers can be proud of – when we contributed in it.

There are three key principles to success: Communication, Trust, and Enthusiasm

Communication

Communication, communication, communication. I can’t stress this enough. Making sure everyone is on the same page is critically important, especially when you’re building a product a continuously changing product. In a fast-paced environment, a developer may take harmful shortcuts or forget important details if the rest of the team is not aware of their actions. Many times, I had to remind a team  member about a requirement he forgot, or explain the reason for our design the third time to the same person. It’s annoying, but it’s far better than letting developers make assumptions and cause irrepairable damage to the project.

Given that the team is potentially distributed all over the world, communication is harder but not impossible. All the team should sit together (via Skype or similar) to agree on a “communication plan”. In our case, we had two teams: client and server which works on different places with different time zones. we decided that everyday the server team would build a new version at 12:30 pm, then the client team would check to see if there’s any problems. Then, at 4pm when everyone in the server team went home, the client team will begin their work and give feedback to server team by the next day. The check at noon guarantee s that the build is not broken so badly that the client team can’t fix it.

One of the other ways to enhance communication is building a “responsive” culture. “Respond early – respond often” – that’s our motto. When you get an email and don’t have the chance to read it thoroughly, just mark them as “to read” and send a message that you’re doing on another task and will look at their problem as soon as you’ve time. That will help the people on the other end switch to another task in the meantime. (*)

Trust 

Believe me, trust is very important. If people think you are not doing your best, they won’t either. Trust others and they will trust you. Do your work so that your team can trust you, and they will be much more inclined do their work. Be as transparent as possible. Make it clear what you’re working on. All of those things are easy to say, but it requires attention and care to get them done.

Once, I joined in a start-up where everyone was eager about what we were going to build. But we were located in different countries, and also had day jobs. Several weeks passed and we got our infrastructure setup ready. But then we got stuck in a vicious cycle: late response time, endless discussion about what the project will do, and soon everyone was tired of meeting without seeing anything done. The project got cancelled.

The lesson to be learned here is: we wanted to build something, but we failed to show each other that we wanted to put forth our best effort. As a result, any trust could have been cultivated was destroyed.

Enthusiasm!

Share your vision. If you don’t love what you’re doing, you are killing the morale of others. We all love working in a enthusiastic environment, so just make it :-).

Being passionate about the project’s goal is a sure path to victory: I have noticed that when myself and other team members have a positive attitude, all team work better with less conflict and miscommunication. We even feel much better.

Enthusiasm is infectious. Coming up with new ideas (sometimes stupid) is a way to show passion. That means you don’t only do your work, but you do it with heart. If you think of any cool idea, tell others right away. Don’t be lazy and say: “I will catch up with him tomorrow” because that tomorrow will never come. Tomorrow, other tasks will pull you away along with your best ideas. If you think the idea is not mature enough to present, put it off somewhere you will absolutely look at when you have free time. I feel that a sticker right beside the monitor is not a bad idea.

Last but not least, keep a close eye on what’s going on. Revise early, revise often. No matter what you’re doing, which role you’re playing, you should be responsible about project’s success. Tell the people in charge about any risk early.

In closing, a programmer is not simply a technical worker. That’s not the spirit – any laborer can learn their work for once and apply it the same way for many years, but that’s not us. We live and breath in the ever-changing technology environment, and we come here because we love it. Working in a distributed team is not only a difficulty, but also a challenge that many of us seek to overcome.

(*) Manage your time wisely. Time management: Answer too many requests and you will not get anything done. Don’t answer then they will wonder why you don’t respond. They can’t see you are busy. Balancing the workload is an art. But for starters: Speak the truth and try to be as simple and as clear as possible.

(**) The images used in this post are credited for Stock Exchange

Some time ago, the development team at my firm staged a revolt against the sales team and senior management: our demand was that no Statement of Work was to be sent to a customer without first being reviewed by a member of the development team.

The message was clear: “We refuse to be held responsible to deliver on terms in which we had no say”. Today it’s not uncommon for a senior member of a development team to author a SOW in its entirety. In many ways they are better equipped than sales staff to write a SOW. They are good with documents (questionable), are very detail oriented, are great at finding loopholes, and at breaking down large ideas into small, manageable chunks. Today I would like to explore an important aspect of any Statement of Work: the pricing model.

Though there are countless pricing models in use throughout the world, the two that are most prevalent in the IT world are:

• Fixed Price (also referred to as Fixed Fee)

Both the price and the scope of work are set in the SOW and neither change without agreement from both parties. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A.

• Time and Material (T&M)

The buyer agrees to pay a set amount per hour plus the cost of materials and other expenses. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A per hour of effort needed to produced, Y and Z. You (buyer) will also reimburse me (seller) for any expenses I may incur (Hardware, travel etc.).

The major difference between these two is who bears the risk if you exceed the estimate. With Fixed Price, it’s you the IT professional who bears the risk. With T&M it’s your client. Regardless of what pricing model you choose, you will need to estimate what it will cost to perform the work (even with a T&M contract the client is going to want an estimate before signing it). As the professional, it is you who are responsible for the estimate, and logic would follow you should stand by your estimate and accept responsibility if it is off.

That said, any time you take additional risk you should be compensated for it. As a rule of thumb I would recommend charging a 20% premium on a fixed price contract over a T&M one. So the same contract under a T&M pricing model (assuming you are spot on with your estimation) will be 20% less than a fixed price one.

Based on the premise above, I propose the following: You should adopt a policy of always choosing Fixed Price over T&M unless you have a good reason not to. Before I delve into the details of what exactly is a good reason to choose T&M over Fixed Price, I want to dispel a few myths:

Myth: Risk is bad

Fact: Risk is an opportunity to make (or lose) money. It’s neither good nor bad. As I have stated above you can easily earn 20% more just by accepting the risk associated with your own estimate.

Myth: T&M pricing protects you if you exceed your estimate.

Fact: If you exceed your estimate, even with a T&M pricing model your client will fight you tooth and nail over the overage, even small overages (This is even more true in today’s world of tightened budgets). Often he will refuse to pay above the estimate forcing you into a compromise. Getting new business from this client will be substantially harder next time.

Myth: With T&M you don’t need a change control process.

Fact: You will need to show hard evidence explaining why your estimate was wrong. The only evidence worth anything is client signed change control documents that clearly outline the cost of the change.

Myth: With T&M, the client benefits if you are under your estimate.

Fact: Consulting firms will simply not leave money on the table.

Myth: Incompetency in your firm’s ability to accurately estimate is a good reason to choose T&M

Fact: Unless you are upfront with your client about your inability to estimate a project choosing this reason for T&M is unethical. You (your firm) are professionals; you sold yourself as experts with statements like “We’ve done this kind of stuff a hundred times before!” If you cannot properly estimate a project, you have no right to call yourself experts on the subject matter. If you would never tell your prospective client the real reason you are proposing T&M, your reason for choosing T&M is simply not valid, and likely unethical. You did the Estimate, you are the expert, and it’s your job to know how long it will take and what problems may arise. (I’ll say it a second time: You are a professional; accept responsibility for your estimates)

Myth: Double your estimate, just to be safe.

Fact: This myth comes in many varieties, which can range from adding 15% to quadrupling your estimate. The truth is, doubling your estimate will simply make your bid uncompetitive (or unrealistic), and you will lose the contract to a competitor. (Three’s a charm: You are a professional; accept responsibility for your estimates)

Myth: Developers don’t need to know the pricing model.

Fact: Everyone on the team needs to know the pricing model. It effects every decision the team makes that involves effort. Who is paying for the effort is always a factor in such decisions.

Okay, so what is a good reason to choose T&M? A good rule of thumb is “If you are unable or unwilling to give your client a solid estimate AND you can explain the reason you can’t (or won’t) in a way your client will understand and respect you should go with T&M”. Keep in mind that just because you can’t (or won’t) estimate a particular task, doesn’t mean that the entire SOW must be T&M. You can specify T&M for some tasks and Fixed price for others). Here are the most common examples:

• Insufficient data to properly estimate it: Your client is asking you to migrate data from an internal proprietary system to a new system you are implementing. Your client says the data is clean and properly normalized. Because you have nothing other than your client’s words to go on, your client should accept the risk of his information being wrong.

• Your client wants to take part in the project in any way: If he is providing resources (ie internal developers or another vendor is participating that the client is managing) or if you are working on site, you should go T&M. You should not be held accountable for the performance of your client’s resources where you are obligated to ensure they succeed. Chances are high that you will wind up performing this work in its entirety, while fearing to tell the client that his trusted employees are incompetent.

• Your client has a culture of excessive meetings and bureaucracy: This kind of culture tends to exist with larger fortune 500 type firms. The only way to work with this kind of client on a fixed price basis is to specify in the SOW exactly what kind of documents will be submitted and how many hours of meetings will be attended. Often the client has to do days research just to get you a list (and templates) of documents that need to be submitted in order for the system to move from one environment to another. Unless you have a history with the client this is hard if not impossible to estimate.

• Your client insists on T&M: This usually happens after you have built a relationship with your client; he trusts you and no longer wants to accept the risk and rewards (the 20% discount) of T&M.

• Your client is looking for a support contract: With support contracts, instead of defining specific work to be done, only the type of work to be done is specified, and it is performed as needed.

The last point I want to make is this: if you are bidding on a very large project I would strongly suggest that you split the project into phases with separate contracts. The first phase will deal with requirements gathering and system design. Once that phase is done, you will be in a much better position to properly estimate the effort required for the development phase.

When your estimates are accurate everyone wins.

Students programming in main room

Each year the Belgian Microsoft Innovation Center (MIC) runs a program to introduce future graduates in software development to local startup companies. The students come with their enthusiasm and eagerness to learn; the Startups arrive with innovative and exciting projects and the MIC provides the infrastructure and support. This year I had the pleasure to manage 24 students over 19 projects. I’ll explain how we did it.

In addition to the equipment necessary for project implementation (laptops, office, subscriptions, software, etc…) we organized many activities. The purpose of these activities was to increase significantly the level of our future developers’ professionalism while ensuring the proper conduct of the projects for our local businesses. These activities included among others: training, collective code reviews, coaching and each trainee had to give presentations.

Training

Controlling a claw built with Lego Mindstorms with his mind using Emotiv Headset

There was nothing very special about the training except the emphasis we gave to interactivity. One thing we noticed was that instead of covering new topics we were trying to complete the learning that students had achieved during their studies. Here are some of the topics we covered:

• Coding guidelines
• Source code controllers (We used Mercurial on BitBucket.org)
• Unit Testing
• Design Patterns
• C # in depth (inspired by the book of the same name)
• Agility in general
• Scrum in detail
• Effective Logging & debugging
• Basic concepts of project management software such as backlog management

We believe that these issues need to be fully integrated into university/college curricula. This would allow us to focus on even more advanced subjects.

Collective Code Reviews

a Collective Code review session

I regularly organized what we call a collective review of the code. This does not mean that everyone read all the code – that would be inefficient.

I read each trainee’s code and when I came across a problem, I would put a screenshot on a powerpoint slide. The next slide was a copy of the previous slide but with arrows showing the errors and a third slide was a screenshot of the code as I would have liked to have seen it. One type of error was added to the presentation once. For example, “poor management of exceptions” was examined only once even if it was a widespread problem found in most projects.

All the students would gather in the conference room to see the presentation. For each problem the first slide is shown so that the group could review it and identify potential problem with the code. Very often, one of the interns suggested the right solution straight away. The slide that highlighted the errors was then displayed and a discussion took place. Finally an example of corrected code was shown (third slide) so that everyone would get the benefit of the “lesson”.

Occasionally, good practice was suggested which always generated discussions and suggestions.

The learning method proved very effective. Students loved the performance aspect since it is very interactive and it always close to the problems they face.

Coaching

A student programming Nao

In addition to formal learning, intensive coaching has been implemented. At any time, I could intervene to help trainees to advance the project. I was fully dedicated to that during the whole period. They also had the opportunity to come and see me to ask technical questions whenever they could not find a solution online in less than 10 minutes (on Stack Overflow for example). Rather than handing out fish, the technique of coaching was to teach them how to fish. We placed an emphasis on developing the student’s capacity to learn while giving them the ideal conditions for the rapid acquisition of new knowledge. Coaching also included informal learning and covered all the things that are more difficult to cover during presentations to the group. Here are the different subjects which have been covered:

• Continuous integration
• Blogging
• The use of a project tracking tool (we used Trello see below)
• How to write an effective resume
• How to interview
• How to gain certifications (Microsoft ;))
• The attitude to adopt in the business environment

The last point was particularly important to me. Throughout the internship, I stressed the one point that I think will make the difference between them and other developers: the ability to solve problems and not create new ones.

Project Monitoring

A team using Trello with the Microsoft Surface

Managing the project was a very important part of the project. In fact, following 24 people in 19 projects is not an easy task. We naturally chose to set up Scrum and used a task management tool of the kanban type. Trello was chosen for its ease of use.

We formed four “virtual” teams based on project similarities, included in these “virtual” teams were two real teams of 2 or 3 people, Alongside our desire to maximize the output, we had a secondary objective to get the trainees to live Scrum and agility in general through real scenarios, some exactly as in a large company. So we had the daily scrum, the sprint review, the retrospective and a lighter version of the sprint planning.

Scrum has proven very effective in this type of program. We plan to integrate even more companies in the process. Although I took the role of “Product Owner” on this occasion we think it would bring more if the course tutors played this role, after training.

Trainee presentations

Students had the opportunity to prepare and make presentations to the group of students. These presentations were in addition to what was originally planned in the program and has allowed the students to practice the art of presentation but has also allowed them to share their new learning with the other trainees. Subjects covered were:

• Introduction to HTML5
• MEF (Managed Extensibility Framework)
• Work with Blend interfaces
• Introduction to Windows 8
• Introduction to XNA
• Introduction to ASP.NET MVC
• Deploy a WCF service in Azure
• Object Mocking
• Get organized with GTD
• The pattern MVVM
• Introduction to Programming Kinect
• Which company to choose?
• Introduction to Silverlight
• Debugging with Visual Studio.

We believe that a great developer must learn to communicate his knowledge and this exercise is therefore one of the things we will continue in the future. Indeed, in addition to these presentations, we encourage our trainees to develop a presentation video by making the appropriate equipment available. In business, those who are able to communicate well are often those to whom we entrust the most responsibility.

Conclusion

Programming the Kinect for Windows

How will we know if this program will lead to better performance from the students in comparison with other internship models? That’s the question we asked ourselves last year.

This year we have developed a proficiency test that measured several dimensions that we believe a developer must master. As we predicted, the score at the start of the program was pretty bad. At the end of the course this score had, on average, doubled!

Despite this result, we cannot say today that our program will have had an effect significantly superior to another approach, simply because we did not have a control group. We hope to do this in 2013.

I sincerely hope that other companies will be inspired to create a similar program within their specialism. I am also very interested in any form of feedback or to hear of your experiences – you can contact me in the comments.

You can see a video introduction to the program here.

In addition, one of the project participated in the Imagine Cup 2012 and you can watch the video here.