Hugo Troche's blog

Project Turnaround Specialist Challenge: The project is not delivering what the scopes states it should

From a project management this is one of the worst problems to have. The solution you are delivering does not solve the problem it is supposed to solve. The first course of action in this situation is to find out if the problem is that the solution does not fit the agreed scope, or if the agreed scope does not fit what the stakeholders where expecting of the solution. There is not glimmer of hope for you in any of these situations. If it is the first case, the project manager failed to communicate and enforce the scope to the developers. If it is the second case, the project manager failed to gather the correct specifications from the stakeholders and then manage expectations. Let's explore what to do in each of these situations.

The solution does not fit the agreed scope

In this case you need to identify quickly:

a) What part of the scope the solution does not cover.

b) What part of the solution is not in the scope.

c) What part of the solution addresses the scope in a wrong way.

Hopefully most of the scope problems will be related to a). This just means that the solution is incomplete, not wrong. Therefore you just create a project plan to implement the missing features. At this stage I would not worry about b). Remove all the unnecessary features last. You still have to remove them, but maybe you can reuse them before the project is over. The most tricky problem are the features that you identify as falling in the c) category. The question is whether to modify the features or just start them from scratch. You will have to make that decision on a case to case basis.

The agreed scope does not match with the stakeholders expectations

You have to define how real this problem is. Maybe the stakeholders just expected the solution to look different. In which case a few cosmetic adjustments will do the trick and there is not need to setup a process to deal with this problem.

If you find out that the problem is deeper than simple cosmetics, then you need to stop all development. If you are developing the wrong software, there is no need to keep developing. I know this is hard to swallow, but it will show the stakeholders how seriously you take their concerns and also hurry them into giving you detailed feedback.

Once you stopped development, you need to organize a meeting with all the stakeholders and go carefully over the agreed requirements. Map for them requirements to features. Then ask your stakeholders to point to you where the requirements don't reflect what they are expecting, or where your translation of requirements into features is not producing what they are expecting. Do not go into this process lightly. The best way to make sure that stakeholders are serious about their concerns is that they agree to stop development until the review process is over. If they don't agree to stopping development, their concerns are probably not big enough to derail the project. You still need to address them, but they shouldn't break your plan.

Cost overruns in software projects. The contractor slack combo.

The is the third entry in the Software Project turnaround specialist series. Cost overruns in a software project come from many places: You end up needing more licenses for the IDEs, more servers, more etc. These are the obvious and easy to manage cost overruns. I have found that the cost overrun that always creeps on you is the man hour cost.

If your organization is like most software shops you employ a good number of contractors that get paid by the hour. These employees (like all employees) get paid whether they work or not. The main difference is that if they work overtime, they get paid extra. I know this is obvious, just hang on for a minute. So, you contract a developer to do 40 hours of work. Since he or she is a contractor and you are not sure of his/hers abilities and you have a tight schedule you assign tasks to that developer that are not on the critical path.

As we all know, the main difference between tasks in the critical path and tasks not in the critical path is slack. A task in the critical path has 0 slack. Which means, that if that task is delayed the whole project is delayed. A task not in the critical path has slack. This means you have a cushion of time that the task can be delayed without delaying the project. Now, suppose that you assign task C to a contractor. Task C is not in the critical path and has 10 hours worth of slack. So, if task B that task C depends on is 5 hours late, task C is still on course and in good shape.

Let's say task B is five hours late. The contractor was not able to start task C until task B was completed and it was 5 hours late. In project management theory this is not a problem because task C has a slack of 10 hours and it is still far from threatening the project. What did your contractor do for the 5 hours he/she had to wait to start task C? Nothing. The contractor just charged 5 hours to your project without producing anything. It is not his/her fault. So now, for a task that takes the contractor 40 hours, you actually paid 45 hours. Are you following me? Multiple this by tens of contractors against many tasks not on the critical path and you are over budget, without ever making a project management mistake in theory. You kept a close eye on the critical path tasks, put your best resources on those tasks and assigned your least tested resources to tasks with slack.

If your budget was based on the sum of the number of hours all the tasks with take, plus an error margin, your budget is probably too low. You must take slack time into account for contractors (and also permanent employees). Consider the worst case scenario slack situation for each task and add the cost of that time to your budget. This problem occasionally is even more obfuscated by the fact that when contractors are not working on a particular task they charge their time to an overhead account that you don't have access to. Then, when you look at the time their worked on your tasks the numbers look good, but when finance runs the numbers they don't.

Remember if your cost are high and there is no easy answer (software licenses, servers, etc), there is a good chance that the contractor slack combo is getting you.

Project Turnaround Specialist Challenge 1. The Project is Late.

I see this problem all the time. And I also see all the cliché knee jerk reactions to it: hiring temps (never works, Fred Brooks in “The Mythical Man Month” actually found out that adding resources in the middle of a software project slows the project down). Threating developers with dire consequences if they don't finish their tasks on time. And the crowd favorite, starting a death march with twice daily status meetings (one at 7:00 AM and the other at 7:00 PM) that everybody is required to attend.

If you are going to remember anything from this entry, remember this: Problems with the project schedule are the project's manager or team lead fault. You can't blame the team, can't blame vendors, can't blame senior management, can't blame other stakeholders. If you are in charge of the schedule it is your fault. Senior management will hold you and no one else accountable. Moving to the good news, you get a second chance to fix the project. If you read my last blog, you know you will not get a third.

This is what you need to do:

a) Find out how much work in relation to the total has been done. You need to be able to tell senior management with the backing of numbers that X % of the project is done. For example, if you are using Extreme Programming as your software process, you need to rate the user stories by difficulty and then calculate the teams user story velocity. User story A takes 1 unit of time, story B takes 2 units. Then if you are done with user story A, you are 33% done. This is the type of logic and numbers you will need to present to senior management to give them confidence on the state of the project.

How yo calculate where you are depends on your software process, historical data, etc. For example, you could a system like COCOMO II to get and estimate on time with an input of lines of code or function points. Again, this is not about how you calculate this number, there are countless methods, even I contributed to the literature with an article on how to use Design Patterns to Estimate lines of code in a project.

b) Once you know how much of the the project is done, create a new schedule with that number as a reference. The completion of the project will now be past the original deadline. With your numbers you can defend your position that the current scope will not be completed until the new date. If the stakeholders want a product by the original date the will have to reduce the scope.

This is the part in your negotiations that I call cliché storm. The stakeholders will come up with all kind of ideas on how to “motivate” the team to produce more. Be ready, read Fred Brooks, read “Death March”. In these books you will find suitable answers to most “motivational” techniques. Microsoft did a study to find out how many hours their software engineers really worked during the day. Because of the culture many engineers were at the office for 10 to 12 hours every day. What the study found out is that only 8 hours were actually productive, the rest of the time was used doing personal chores, gossiping, water cooler talk, etc. It is very difficult for an information worker like a software engineer to be productive for more than 8 hours a day. Find research like these on line and in books, be ready to show it.

If you can't sell the new schedule or reduced scope, your project is doomed. There is no “Magic Silver Bullet” (another great Fred Brooks book). New resources will not help, “motivation techniques” will not help (they will actually hurt because of turnover and poor quality to meet deadlines). You need to change the scope or the schedule.

Turning a project around

This is the first of what I hope a series of entries on practical advice on how to turn a software project around. Before I start on the subject let me tell you a story.

It is said that the great master of warfare Sun Tzu (author of the Art of War) was once trying to convince the Chinese emperor that he would be a great general to lead the emperor's troops. In order to prove that, Sun Tzu told the emperor that he could make the emperor's concubines behave like soldiers in a manner of minutes. To which the emperor laughed, the concubines did not even take the emperor's orders seriously. The emperor told Sun Tzu that if he could make his 100 concubines behave like soldiers, Sun Tzu will be the commanding general of the army.

Sun Tzu called out all the concubines, gave them spears, and told them to form in two columns of 50 concubines. At the front of each column, he placed the two favorite concubines of the emperor. He gave each of the two concubines the rank of lieutenant of the concubine army. Rank which the concubines whimsically accepted. Then he told the 100 concubines to face him while holding their spears in attack position. The concubines found this a lot of fun and followed his instructions. Then Sun Tzu grabbed a war drum and instructed the concubines to rotate 90 degrees to their right every time he beat the drum. At the first beat the concubines tried to rotate and started laughing when nobody got it right. Sun Tzu told the emperor that the first time troops make a mistake is usually the fault of the general. Therefore he would repeat the instructions and make the lieutenants responsible for the outcome. He explained the drill to the concubines again, and made a special mention to the lieutenants about their responsibility. So, Sun Tzu beat the drum again with the same results as before. The emperor and the court were truly enjoying the spectacle and laughing with the concubines.

This time Sun Tzu said that since he already repeated his order twice, that the fault was with the lieutenants. Therefore, he would cut the head of the most senior lieutenant off as an example to the others. The emperor jumped out of his seat and told Sun Tzu that he indeed appreciated Sun Tzu's wisdom and the first general opening will be Sun Tzu's. Sun Tzu told the emperor that training the concubines was his duty and that the emperor agreed to the task, therefore he should be given the liberty to finish the task. The emperor knew he had to let Sun Tzu finish. If he didn't, it will be known that the emperor went back on his word. Not a good reputation to have among generals. With the emperor looking by, Sun Tzu cut the head of the emperor's most beloved concubine. Then, he promoted the third most beloved concubine to lieutenant and told the second most beloved concubine that she was in charge. From then on the exercise went flawlessly. The emperor made Sun Tzu commanding general the army. Sun Tzu went on to win countless wars, many of them without ever fighting a battle.

The moral of the story is that if you are general, you should be ready to cut the head of careless lieutenants. If you are a lieutenant, you only get two chances.

I find this to be true with projects also. If you are managing a project, and the project gets in trouble, you will usually be given a chance in the form of time and resource to fix it. But, if you fail to fix it after that, well you read the story.

From the perspective of senior management a project is in trouble when:

a) The project is delayed and behind its planned schedule.

b) The project is costing more than planned.

c) The project is not delivering what the scope states it should.

If you want to become a software project turnaround specialist that walks in after some heads have rolled, or if you like your head attached to you shoulders you need to able to quantitatively identify to senior management why a), b), c) or a combination of the three is happening. Simple saying the schedule is too aggressive or I don't have enough resources will not do. You need numbers to back these claims. In my next post, I will explain how to use software duration estimation techniques to come up with a real time estimate for a project.

Simplifying Deployment

A common problem that my customers face when developing and deploying Enterprise applications is how to keep all the different application server instances configurations synchronized. What I mean is, how to easily make sure that the development application server, the QA application server and the production application server have the same configuration, and when the development application server changes, what is the process to move those configurations changes to the other application servers. I am not talking about application code itself, but the configuration files and directories on the servers. I see this issue even in organization with a mature software process.

I have seen many solutions to this problem. Most of the time the solutions are depending on a technology, are manual and poorly documented. Here are some examples I have seen:

- README notes. I have to admit I have a soft spot for README notes. As a person heavily involved in Open Source, I am used to getting building, installing and upgrading instructions from README type documents. These notes alone just don't do the trick. They can be an important instrument in the process.

- Saving entire application server configuration directories in the repository. This one is a bad idea all around. For example, I have seen applications being moved from development to production by copying the entire server directory to production. To do this in JBoss, you would copy the directory //DevelopmentServer//%JBOSS_HOME/server/default to //ProductionServer//%JBOSS_HOME/server. This is bad because that instance of the server is only useful for the one application you are deploying. Deploying another application to that instance is difficult and complicated. Also, the possibility you will have broken file links is high.

As an enterprise architect the first thing I do to solve this problem is first to create a non technology specific strategy that can be instantiated to a particular technology stack. The plan will look like this:

a) Push as much configuration as possible to the application resource file (.ear, .war., .sar, etc).

b) Define what configurations can not be pushed to the application resource file. For example in JBoss that usually is : xxx-ds.xml, xxx-service.xml, login-config.xml among others.

c) Create a repository project separate from all the applications where you keep those files. Tell developer that their configurations have to play nice with everyone elses.

d) Create scrips with Ant, Maven, etc that automatically get those files from the repository and place in the correct place.

As a deliverable of this solution you should provide documentation of what can't be placed in the application resource file, a repository project for those files, scripts to automatically perform do the update to the servers from the repository.

Let me know if you have any questions.