Silver platter and the doom of custom made software

Silver plattering is a made up verb that refers to giving to the customer more that what is in the scope of the agreement. Basically, you give them your work for free while smiling, you give them what they want in a silver platter.

As any good negotiator might tell you, it can be a good deal if by giving a little you get something else, but it can be the doom of a project if the silver platter starts and never ends. When working in projects, be aware of the risk of silver plattering. I  sank a 7 year old company just because I was not paying attention to it. Believe me, its a high risk.

The expectation that the contractor change indefinitely a software is quite common in organisations that don't have mature processes and don't have a clear understanding of software development practices. It basically describes most organisations working in a undeveloped software market, Colombia for example.

For example, they want the software to fit the process, but they keep changing the process and expect you to develop the change again and again. One that is happening to me right now is that the requirements are given to you with little or no details, for example lacking special cases or precise data that needs to be saved. Then, when the testing starts you are expected to change it again and again for not being a good psych and developed exactly what the customer had in mind but forgot to write down.

What to do? Its as clear as water. Don't give your work for free, no matter what happens. It you loose a client because of it, it might be better for you. First, be sure to include in the contract a clear definition of change and defect. Second, include in you plan a specific milestone for client approval of the requirements and don't start development until you have a valid signature. Then, stick to your process like a fly to honey.

When asked to do a new change because its the "last one", just say no!

Normalize, but not too much

 Its common to have understaffed projects. People get recruited just when the team starts to get behind, but not before in an attempt from administrative staff to save some money. If team members can barely finish their jobs on time, they are not very interested in making advance reports or help you define how much time it will require the next task. They are tired, and they don’t see the point, since their perception is that the job gets done just because they don’t get to see their families. In this scenario is quite difficult to gather information for planning and control.

Still, if you are at the PMO, you are aware that knowing the status of the project is as important as doing the job. That is why it is your job.

How to do it? I found that adapting to the team worked properly, and try to find information in the format that is more natural to the person doing the job. Some people have organized tables where they keep track of everything, some just keep the record in a board with post-its. I just took their particular methodology, analyze it and talk them into including additional information I needed. For example, making the reports with the same periodicity or adding one more field that will allow me to have the statistics I needed for the reports.

I was able to get normalized data from all fronts of the project without having every team member filling specific formats. It just worked for me, and I guess for them, since they never felt my reports to be a burden.

 

Just a new remainder that projects are made by people, and that your need to normalize PM data should never imply you have to normalize the people you work with.

Estimations

I remember the first time I heard about Delphi Estimation*. It was my first undergrad course on software engineering. I couldn't stop laughing for a while, how can you base the whole project plan on some persons guess? It sounded so stupid, I kept making jokes about it for a while.

Many years later I found my self having a great deal of respect for estimations based on experienced persons "guesses". Delphi method just growed on me, without me even noticing.

I can now see at a proposal and just know if the estimates are good or not, by heart, I just know. During the last decade I acummulated experience and I am able to classify requirements by risk, know what can be done fast and where the programmers are being just too optimistic, in mi head in minutes.

But this gut feeling wasn't given to me by the gods as a gift, it was built with hard work. I have records of times of the work I have done, for years. Every day I record how much time I spent in each project or activity. Not histericaly, with seconds, but just a rought count each day. Every month I take an hour to summarice it and check if my estimates were correct when I planned my activities. Some times my estimates where acurate, some times they weren't. I learned from the mistake and managed to improve my estimates for next month.
I then started doing the same thing with other's people's work. I created a way to classify requirements by complexity (a personal simplification of the function points, that latter learned, are called use case points). I used to estimate how much time a team needed to develop a set of classified requirements. Then I measured, and compare my "guess" to reality and learned from the mistake. I made this for years and still do it, every day, even with the smallest simple task (like checking expenses from a trip, or reviewing a report).

I learned this wonderfull trick in the same class where I learned the Delphi method. I was "forced" to used the PSP (Personal Software Process) that includes keeping an engineering journal with notes of your work and time taken by different activities. My journal was then a ridiculously pink Hello Kitty notebook, now I just keep it all in google docs files. I will record in a while that this post took me about 40 minutes to write (including finding the magic eight ball picture), and hope that after the 5 minutes it took you to read it, you are curious enough to check the PSP and keep a journal. Believe me, its worth every second spent on it.


* Sorry about including a Wikipedia link as a reference, couldn't find a better link to explain the Delphi Estimation. If you have a better reference, please let me know, I will gladly replace the link.

Just read the PMBok book! (or not)

I still find strange that Project Management Best Practices are uncommon or not known by companies working with Engineering Projects. 

Being common in the Engineering(or almost any) discipline, projects represent doing something specific, like creating a new product, in a predefined period of time. Since the idea is to do it efficiently, using developed techniques (even templates) would be an easy way, a natural shortcut. Yet, many people still think that Project Management happens magically if you put many people and give them requirements to fulfill. It doesn´t, and after some time, the team ends up frustrated and the requirements, if fulfilled are done with pour quality or triple budget or time.

The Project Management discipline has been around for 30 year or so. There are hundreds or books, blogs, websites on the subject. You can take courses, even post graduate programs, or get certifications that are recognized worldly (like the PMP). Yet, still, in some organizations it’s a completely new and novel approach.

If by fate or choice you end up in such organizations, you might spend much of your time struggling to get your boss to read the damned PMBok. But it might not happen. It they made it so far without it, why will they want to change their approach? According to their experience, projects are messy but somehow get done.

Do you want to give the fight and try to change your organization? If you do, my advice is not to battle but show how project management techniques can solve daily problems efficiently. Take little steps, don´t fight (creating more chaos into the chaos). Remember one of the most important responsibilities of a PM is communicating. Make sure all people have the information they need when they need it, and that issues are properly communicated to the involved before becoming an issue. This talking, is nothing else but coordination. If you are able to do this successfully, you have gained a lot, and made a big step in the right direction.

Then, start using planning techniques to eliminate the sense of  "no control" your team might be experiencing. Start by doing a simple work break down structure, a list of tasks and a Pert diagram. (Try not to call them that, you boss might think you are bringing those hippie PM things). Planning means nothing if a team is not committed to fulfilling it. Try doing that, but just talking to people. A Schedule should not be enforced, but sweet talked into people. If the team is convinced the planning is right and the due dates are required to make it all work, you will then have a very decent planning and will be able to follow it and see significant delays.

Budget will not be hard to include into the plans and follow ups. Next step, will be to plan for quality. Both can be done by slowly including into the plan control activities. If you do all this, probably the project is over and you had a lot of work in it. But you will have interesting data to show your boss and your bosses boss. You can show results of using project management techniques and have arguments to keep on the battle for introducing the best practices you know really work.