Excellent Blog: David's Software Development Survival Guide

Hi everybody.

I just came across this blog: David's Software Development Survival Guide. I like it a lot and if you like my blog (more or less), you'll like that one too.

David writes about similar topics as I write. His material is very informative, very practical. It clearly shows that he's been around and learned a thing or two (and more). He provides a good mix of theory and practice, formal and informal. Highly recommended. I have also blogrolled him (on the right). Take a look.

Keep up the good work David and thanks.
---------------------------------------------------------------------------------------

Technorati Tags: Project Management, Project Manager, Software Engineering, Software Project Management
---------------------------------------------------------------------------

Story Time - Stakeholder Management

This really happened to me. Naturally, I hide identifying details.

Several years ago I got a contract position as Program Manager for a startup company. The company had just signed their first contract with a very large client. This was a do-or-die thing, so they figured it was time to bring someone in to make sure the project gets done properly.

The company had four executives:

• CEO, who was also the founder
• CTO who was also a co-founder
• VP1 who was the son of the chair of the board (smell trouble? No kidding)
  
• VP2

It took me two weeks to realize that I had landed right in the middle of a major war within the executive layer. The war was over the future strategy of the company. Actually, over the future of the company.

Camp 1: CEO and CTO: think the company is viable, has a great future and needs to continue with the current strategy.
Camp 2: Chair (daddy) and VP1 (son): think that the company is OK right now but will not succeed long term. Therefore, it should be sold ASAP to recover the investment.

I was the only manager in the company (other than the executives), so I had to somehow keep the boat afloat while the gods were fighting. I focused on the success of the project and did my best to stay out of the line of fire. But, as these things go, the line of fire chased me. I soon became their secret ally. One day one camp would sit down with me, tell me their secret war plans and urge me not to tell the other camp. The next day, the other camp would do the same. I listened politely but stubbornly avoided becoming a part of that in any way. From my perspective, each one of the executives could fire me in a blink of the eye if he thought I was siding with the other camp, so it was clear to me that the smartest thing was to stay out of that war as much as I could. So I continued to "stay the course" (ouch, not the smartest choice of words these days...) and concentrate on the project execution.

But things turned very problematic very quickly. It turns out that as the war intensified, the camps started with more personal and direct criticism and accusations. And so, an argument (one of many) broke-out: was our product ready for prime time or not? VP1 and VP2 claimed that the product was in a prototype state - not ready for prime time, which proved that CEO and CTO were incompetent. CEO and CTO claimed that the product was mature and ready for prime time, hence, they were doing a good job. Daddy-chair secretly sided with his son (VP1) but could not do so openly. So, the BOD was looking for somebody neutral but knowledgeable to "tell them the truth". And guess who they found. Right, me. My manager (VP1... Son) notified me that I was invited to the BOD's next meeting to "testify".

And then, to make matters worse, the CEO fired VP1 (my boss) ! So, I get a phone call from (ex) VP1 telling me that he had just been fired. He explained to me that he was sure he would be reinstated because his daddy would take care of that. Oh, and also, now, it was more important than ever that I deliver the right message to the BOD. Get it?

So what do I do? Here I was, just doing my job and suddenly, I decide the future of the world. And what's worse, the way I looked at it from my perspective, this was a lose-lose case. If I support camp 1, camp 2 will get rid of me. If I support camp 2, camp 1 will get rid of me. Damned if I do, damned if I don't. Either way, once I "testify", my employment with the company would be very short. This was still the dot com bust time and losing a job was even less fun than usual. I will admit that I had a few not easy days. I had a family to support and all that.

So, I thought and thought and strategised and strategised: which side should I support and yet survive?. I saw no way out. And then I had this eureka: to choose a side is the wrong consideration altogether! I must not choose sides in a political-power war. I must not think what's good for me, I must do what's right! I am first and foremost a professional and I must act professionally. And if I loose my job (I was sure of that) so be it. I just refuse to play along with this political power struggle.

So, the next day, I met with both camps (separately) and officially notified them that they should not expect me to support any camp and that what I would tell the BOD will be my true and honest professional judgment of the status of the project and the product. And after making that statement, I closed my eyes and waited for the ax to come down.

How big was my surprise. First I should say how big was their surprise. That, obviously was the one answer they had not expected. But when they heard it, they liked it! They apologized for dragging me into that war and said that all they wanted from me from now on was just to continue with my work and make sure that the project was successful. Which was what I wanted to do all along :)

I was so happy and proud that I had made the decision not to play the wrong game and promised myself that I would continue to conduct my job by this simple principle:

Be professional.

These are not empty words, It's important, it's the right way and sometimes it even works :).

So, happy ending to this story. Talk about stakeholder management...
------------------------------------------------------------------------------------

Technorati Tags: stakeholder management, Project Management, Project Manager, Software Engineering, Software Project Management
------------------------------------------------------------------------

The Test Engineer is the Project Manager's Best Friend

Or should be...

Over the years, the status of the QA profession has evolved (or, more correctly, devolved). For some reason, it has become the norm to view the QA engineer as some kind of a "second rate citizen" in the project team. Most other professionals, in particular the development engineers, look down on them. The test engineer is considered some sort of a failing development engineer. If you try to be a developer and And, as it often times happens in life, this misconception becomes sort of a self-fulfilling prophecy. Because of the poor image, nobody really wants to be a QA engineer, so only the no-so-good engineers end up "falling" down into this "lower caste" profession.

QA engineers are usually treated with resentment and viewed as a necessary evil and an obstacle on the way to the product release. Engineers treat them dismissively,try to order them around and pressure them to not delay the release. Usually, the QA group is officially subordinated to the engineering group, reporting to the Director or VP of Engineering. This is a clear conflict of interest! The QA people are managed by the development manager whom they are supposed to audit and whose product code they are required to test.

But for you - the project manager - the test engineer is the best friend! The QA engineer is your last "line of defense" in the release process before the product goes to the customer. He/she gives you the last chance to find the problems, catch the unacceptable bugs and generally, give you a professional, impartial assessment of the readiness of the product for release. And they are, by their profession, the most qualified to do that job. As a project manager you know (I hope) that it is so much better if the annoying QA engineer finds all these embarrassing issues, rather than the annoyed customer. So, the QA engineer can save you a lot of embarrassment and headache.

And it is actually not at all true that QA engineering is less sophisticated and technically challenging than the job of the developer. A good QA engineer must have the same technical skill level as the developers. A major reason for the misunderstanding is because too many people think: "QA Engineer = black-box testing". Indeed,black-box testing is not rocket science. However, any good QA engineer must be skilled in white-box testing and this is a whole different game altogether. I can easily find development engineers who will be challenged by QA engineers who implement white-box testing. And what about test automation? How many developers are skilled in building test automation tools? And what about testing of real-time, embedded software?

So, in your project, be sure to get the best QA engineers you can; protect them and support them and take their test findings seriously. If you don't the customer will. And do not save effort to change the team's attitude towards them Everybody must realize once and for all that testing is one of the best things in the release process.

Let me know what you think.
-----------------------------------------------------------------------------------------

Technorati Tags: test, testing, QA, test engineer, QA engineer, Project Management, Project Manager, Software Engineering, Software Project Management,

Cost Management is Not Optional

All too often, I see companies and/or projects where project cost management is not done at all. Project Managers just don't deal with the money aspect. In many companies, the PM is not expected to manage the cost of the project. In some, the PM is even discouraged from doing this.
I saw many organizations where the executives somehow did not even know that PMs can do this for their projects, let alone should do it. When the (skilled) PM brings the topic up and demonstrates how this can be done and how beneficial this is, they are surprised. And happy.
But it is a fact that in many places, PMs are not required to manage the project cost.

The point I want to make in this post is:

Even if you (the PM) are not expected to manage your project cost, you should still do it!

Considering the fact that cost is one of the 3 famous project constraints, this is one of the most fundamental skills that PMs must have and must apply for their projects. And, it is one the most important activities that the PM must engage in. Even if the PM is not required to manage cost, they must feel compelled to do it anyway. At least two reasons:

• For your own professional development. As a PM you must become skilled in cost management. Without some basic skill and experience in this area, IMHO, you cannot be regarded as a senior professional. If you work in a company where cost management is not expected of you, what better environment can you have to practice and learn? And educate the management?
  
• Cost management is a critical tool for better managing and executing projects and programs. Without cost management, it is impossible to calculate such things as ROI, NPV and Earned Value. If a company wants to have a solid project/program strategy, it must use these (and many other) tools. Without project cost management, the company gropes in the dark.

Company financials are not a simple matter at all. In order to perform really good project cost management, the PM must be familiar with general business financial management and the specifics of his organization. This requires from the PM a significant investment in time and effort to achieve a good level of expertise. This is undoubtedly a discouraging factor and may explain why cost management is a 'weak link" in software project management. However, I want to claim that this should not stop the PM from practicing some basic-level of cost management. Two important points:

Even minimal cost management can provide significant benefit
Forget all the company financial policies and general finance management theory. All you need to do is estimate costs and track expenses for your project. That's all. You'll be surprised how many good things can come out of this. And...

Minimal cost management is actually pretty easy to do
Current project management software tools make it relatively easy to estimate costs and track expenses. Here are some guidelines, using MS Project (although any project management software tool can do that).

In MS Project, go to the Resource Sheet. All your resources are listed here. For each resource it is possible to define various parameters. One of them is Std. Rate (= Standard Rate). This is measured in $/hour. All you need to do is enter the rate of each resource in the table. True, usually, you don't know how much a person's salary is but I am sure you can make a reasonable guess. As soon as you entered rates for all the resources, MS Project automatically calculates the cost of each task in your schedule, plus roll-up of totals to summary tasks, all the way up to the full project cost. Plus totals and breakdowns per resource. That's it. So simple, so powerful.

You can also easily add fixed costs (such as purchases, travel expenses, fixed-price consultaning, etc.). Add a task for each of the fixed cost items. Add the Fixed Cost pre-defined column in the table (see MS Project help on how to add columns). For each fixed cost entry in the schedule, enter its cost in the Fixed Cost column. That's it. So simple, so powerful.

Don't forget to baseline.

As the project progresses, be sure to update the schedule to correctly reflect the project status. You update the tasks (start date, end date, percent complete) and MS Project will calculate updated current costs. And with the baseline that you remembered to save, MS Project will also calculate all the Earned Value info for you, full break down and roll up.

Once you start doing this minimal work you will be surprised how easy and useful it is. And when you show it to your manager or executive (who did not even think you could do something like that), they will be delighted and never let you off the hook again.

This is why I say: cost management is not optional.

------------------------------------------------------------------------

Technorati Tags: buffers, Cost management, padding, Project Management, Project Manager, project schedule, Software Engineering, Software Project Management
------------------------------------------------------------------------

To Pad or Not to Pad

To many, this is still the question. We all know this practice. Make some time estimate, then pad it to compensate for... Actually for what not? Overloading, distractions, interruptions, pressure to speed up work, Murphy's Low and what not. Actually, one more: the inability of the programmer to do good estimates in the first place. Even the programmers admit that they are over-optimistic and that their time estimates are always too short.

This typical predicament is nicely expressed in Rita Mulcahy's book, PMP Exam Prep:

"I have no Idea how long it will take. I do not even know what I am being asked to do. So, what do I say? I will make my best guess and double it!"

In general, padding is bad. Again, as Rita explains it, "Padding is a sign of poor project management!". if you are not sure about your team's time estimates, you should treat is as a risk and not camouflage it as hidden padding.

Actually, why is it bad to pad? Here are several reasons:

• Padding means that there is an inherent deficiency in the estimation (and likely in the estimator's skill). By padding, we disguise the problem instead of facing it and dealing with it.
• When the resource sees their padded tasks, they naturally assume that their task completion date is the one that includes the pad. You are giving the resource "extra time" before they even started the task.
• Once padded, the original estimation disappears. There is no way to hold the estimator accountable for their original estimates.

So, what do we, PMs, do? We know that if we take the estimators' input "at face value" we are most likely in trouble right from the first moment of the project. There are all kinds of things that a Project Manager can (and should) do to improve the situation. None of them is a magic bullet but in combination, they can improve things significantly. Here are some suggestions:

• Give them more time. One of the most compromising factors is the time that we (don't) give to the estimator. If we ask the estimator to estimate a task and want an answer right then, we may assume that the estimator is just throwing a number in the air to get us off their back. Give them time and encourage them to use it to think more carefully and wisely.
• Review the estimates with a critical eye. If you have experience in time estimation and in SW development, you can identify cases where the estimation doesn't seem right.
• Let an expert review. An expert will be able to provide a lot of insight.
• Train the estimator in time-estimation techniques. There are techniques for estimating time. verify that the estimators use them.
• Remind them of the implied sub-tasks. Remind the estimator that there are typically several activities included in a single programming task. Once the programmer realizes that, he/she will benefit in 2 ways: It will be easier to make a more accurate estimation and it will help them remember to do all of these things
• Some thinking, planning, designing.
• Prototyping
• Implementing
• Developing unit tests
• Unit-testing
• Fixing bugs.

All the above are things that the estimator can do to improve their estimates. But there are also a couple of things that you, the Project Manager, can do.

Estimate Effort, not Duration

Estimators easily fall in this trap. They think in terms of duration rather than effort. This automatically introduces padding into the estimation process. You need to make sure they provide their estimates as effort. You usually will have to coach them on this and continuously verify that the numbers they give you are indeed effort and not duration. Estimates in duration muddy the waters.

Nobody Ever Works at Full Load

No human being executes their tasks at 100% of their time. People are human beings. They take breaks, rest, take care of administrative things, go to the doctor, etc. When an estimator provides an estimation of the effort, the number should reflect continuous, non-stop work. In real life, this never happens. Project Management SW tools allow you to specify the load level of the resource. I usually set the load of Individual Contributors to 80% and of Managers to 50%. Granted, this is probably a form of padding but it does not come from uncertainty in the estimate but rather from sound experience. It's not an uncertainty, it's a certainty that people do not perform at 100%. The only uncertainty is the actual percentage. This is up to you to estimate.

Add Project-Level Buffers

This is a mechanism that I invented years ago, only to learn that it was a standard element in Critical Chain Management. I found it extremely powerful even if I don't use Critical Chain Management. Here is how it works:

The Gantt chart shows a project with a series of tasks (in Blue). At the end of the project, I added 3 Milestones:

• Optimistic. This is when all the tasks are complete. No buffers, no padding. In the chart it is on 5/18.
• Realistic. This is a date I got by adding 20% to the total duration of the project (from day 1 to the Optimistic milestone). In the chart it is on 6/15.
• Pessimistic. This is a date I got by adding 40% to the total duration of the project (from day 1 to the Optimistic milestone). In the chart it is on 7/12.

As the project progresses a delay may develop in the project end-date. This will cause the first (Optimistic) milestone to move to the right. The other 2 milestones never move. This way we can see how the current projected end-date moves relative to the buffers. In other words, how much of the buffers is being consumed by the delay. This is an excellent indicator that allows the PM to see "how bad things are" and decide if it's time to take some corrective actions.

These are my safety buffers. Generally, I prefer not to show the 3 buffers to my team members. I only show the Optimistic milestone and do not even call it Optimistic. As far as they are concerned, that is the target date that they need to hit. The 3 milestones are for the people that I am accountable to: My manager, the project sponsor, the executives and the customer. I explain these milestones to them as follows:

• Optimistic. We will finish the project on this date only if everything goes perfectly. No delays, no surprises. This is the ideal end date. I have a low level of confidence in this date but I am going to drive the project to this date and try to hit it.
• Realistic. I think this is the date that I can realistically hit and I recommend that you assume and make your plans to this date. I have a good level of confidence in this date.
• Pessimistic. This is the day we will be done if many things go really wrong. I have a high level of confidence in this date.
• If the project runs later than the Pessimistic milestone, something is really bad in the project and we need to reevaluate the entire project.

I used this approach in the past with great success. Managers and customers were very impressed and pleased with this approach. They stopped being fixated on a single delivery date. Now the project is not held by its throat to a single date. There is flexibility but it's OK with management and customers because it is not open-ended. It is bounded. They accept the fact that I do not commit to a single date because they know it's not realistic but they are not worried that I open the door to a runaway project because the end date has a reasonable range.

Let me know what you think...

---------------------------------------------------------------------------------

Technorati tags: project manager, software project management, project management, software engineering, schedule, project schedule

---------------------------------------------------------------------------------

Why Hasn’t Software Development Gotten Any Better?

This is the title of a very good post that Ed Yourdon published in his blog. Highly recommended. Read it and also my comment.

-------------------------------------------------------------------------------

Technorati tags: Software Engineering, software project, software project management

-------------------------------------------------------------------------------

Software Requirements Specification Is King - Part 2

In Part 1, I explained why the Software Requirements Specification (SRS) is the most critical and valuable product document. In this part - Part 2, I will provide some guidelines, suggestions, tips, etc. that Project Managers need to know in order to make the SRS experience good and beneficial.

We will start where I left off in Part 1:

If you don't intend to use it seriously, don't bother to write it.

This is actually applicable to all project and product related documents. So many project teams write so many documents (sometimes even reviewing and approving them) only to put them in the drawer and forget them forever. What's that good for? A frustrating and boring task, expanding resources with no benefit. So, don't bother.

Those of you who have seen a well written SRS know that it's not a trivial undertaking at all. Writing a high-quality SRS is very demanding, both in quality and quantity. This is one of the main reasons why it's often hard to get the team to write it. I have found in my experience that you - the PM - can make things easier if you and the team follow some simple rules.

• Substance is more important than form. In the beginning, don't worry too much about the appearance and format. Just make sure that the info is there. Worry about looks later. In fact it will probably be best to get a tech writer for that.
• Something is better than nothing. Trying to write a full, complete, comprehensive spec in the first shot is discouraging. It's a very large task. Encourage your team to start with something. Start small and add as you go.

These 2 principles will allow the team to start with a relatively small effort and get something started. The team will routinely add and improve and over time the document will be high quality.

Now we want to cover some important principles for the contents of the SRS. I will not cover this material here. There are tons of books out there and I don't need to repeat that. No added value. But I do want to recommend that you take a look at Scott Sehlhorst's article: Big Ten Rules - Writing Correct Requirements. This is a very good review of the characteristics of good requirements. It is probably more than you want to know or do for starters. But as you improve the quality of your SRS, this is certainly something that you should look at. The only thing that I want to add here is: if you start the SRS small, as I recommend, then, IMHO, the most important principle in Scott's blog above is actually the last one - correct. The important point here is: errors are unacceptable. They cause more damage than if there was no SRS in the first place. So scrutinize the SRS very carefully for correctness. Worry about the other rules later.

This is it for now. I covered some principles for generating the SRS. Sometime in the future (sooner than later, if there is interest), I will cover the principles for using the SRS.
Let me know what you think.

 

--------------------------------------------------------------------------------

Technorati tags: Software Project, Software Project Management, Software Engineering, Software Requirements Specification

-------------------------------------------------------------------------------