Promoted to Project Micromanager

Unless you started your career as a project manager, you most likely have to work your way into the position. You probably had a highly technical role as a software engineer or maybe a systems engineer. Whatever your role was, you were the person actually doing the technical work. In my world, the world of software development, many software engineers find themselves being asked to take the role of project manager.

First let's understand why you, an engineer, have been asked to take on the role of project manager. You have probably gained a reputation of being organized. You write solid high-quality code that passes all requirements. Your design documents are well written. You stay current with the latest technologies and methods of software engineering and you know when to apply them. You are known for finishing your software tasks on time and help out other engineers when requested. You have demonstrated that you have strong technical skills and you are a technical leader.

Now you have been asked to manage the next development effort as project manager. It makes sense to most people. There is a new project, someone needs to manage it. Why not appoint one of the best engineers to the role? It's an opportunity to grow and to enhance your skill set. It will be a career development opportunity. Makes sense right? Well, maybe… Project management does require a new set of skills that are not required as an engineer. Many of these are obvious. Scheduling, budgeting, and tracking the progress of work are all project management skills that can be taught and understood by a smart engineer pretty quickly. But the hard part of this new role is realizing YOU ARE NOT AN ENGINEER ANYMORE! ...well at least for this project anyway.

Here is why this can be tough. The number one talent that you have relied on in your career has been your technical abilities. Because of this, you will find yourself wanting to exercise these skills. During the project, technical challenges will pop up and your first reaction will be to jump in and solve it. DON'T! Let the engineers on the project solve them. It's their role now, not yours. Your job is to make sure they have all the resources and time to solve it. There is nothing worse as a software engineer than to have your manager telling you how to write your code. But that's exactly what can happen in these situations.

Utilize Empowerment
So how do you keep yourself from becoming a micromanager? The best technique I use is empowerment. There is no empowerment algorithm, an empowerment Java package, or an empowerment eclipse plug-in. You’ll have to step out of your technical mindset to understand and implement this one. Empowerment can be a tool for motivation and for delegation. On tough projects you need a team of people who are motivated to take on hard problems and to put in the effort needed to get the job done. You can’t solve all of these problems yourself. You don’t have time. So you will need other team members to work on them. Here are a few ways to empower your team:

1. Get them involved as soon as possible. Make sure the engineer estimates the durations for his or her own tasks. If they said a task will take three days, they will put in more effort to make sure they meet their own goals. If you set the task duration to three days, then their extra effort would be to meet your goals. And people like to achieve their goals, not yours.

2. Don't second guess their opinions. The engineer has been heads down in the problem. Trust their opinions. If you even slightly show mistrust in their opinion the problem and the solution becomes yours. Each time your opinion gets implemented, it becomes more your task and less of theirs.

3. Don't start tasks for them to finish. I once had a manager write the JavaDoc, define all methods, and parameters for me to help save time. He then expected me to fill in the code in each of his methods based on his documentation. I second guessed myself every time I had to change anything he did. I must have visited his office twice a day asking him why he chose to do things the way he did. The point I'm making here is when you start a task for someone, you become the expert and they will come to you to make decisions.

One of the main ideas in empowerment is the idea that people like to fill needs. When it is made obvious that no one else is the owner or expert in an aspect of the project, the person working those related tasks will take it upon him or herself to master those tasks. Your engineers will step up and fill the needed role. It becomes more gratifying to them knowing they mastered the challenges themselves and are not the expert.

Making the move from engineer to project manager can be exciting and a learning experience. If keeping out of technical issues is something you can't resist, then think of it this way. Upper management originally chose you for the job because of your technical leadership. Making sure your engineers are able to show their technical leadership will give upper management new candidates to manage the next project and you can go back to being an engineer.

Chasing a Constantly Changing API

I was once waist deep into a development effort when a partnering development team informed us that they where changing their API again. The component we were developing depended on their components for data and capabilities. We had spent time interfacing with their component. We had been careful enough to isolate the interface to their API by creating a façade. This way, the two components were decoupled as much as possible and our component was somewhat isolated from future changes to the partners API.

Our partner was already changing their interface. Not a problem, right? The façade is the only subcomponent affected by this change. An engineer spends a few days reworking it and we move on. It’s that easy right? Well, no.

When this happens you need to make sure you find out why their interface is changing. Ask your partner why this change has been made and why this change was not thought of originally. If they do not have solid reasons for this, then be assured that their API will soon change again and you will find your team spending another couple of days updating the façade. I have seen this situation play out many times. Each time the partner swears that "this is the final change to the API" only to have it change again a week later.

Yes, the façade acts as a buffer to new changes but changing the façade still requires work. And no façade is completely perfect. Some changes might still bleed into other subcomponents causing many other needed changes. In fact, the more you need to update the façade, the greater the chance that the changes will effect all the subcomponents who utilize the façade.

In many situations you have no control over your partner's development practices. It is important to first identify when you may be dealing with an unstable API. Once you have identified the API as unstable, you have a few options other than using up all your resources chasing it.

1. Hold off on making the changes. Wait a few weeks before updating your façade to their latest API. You might also be able to wait till the end of the development effort to make the update. This way, you will skip a few interim API changes. I do have a word of caution on this. Make sure you’re not ignoring their changes; only skip the updates to your code. You want to make sure their changes do not drastically change or remove the needed data or functionalities you require from them. If you wait till the end of development, it might be too late to address the problem.



2. Send you partner your façade. Many partners will pushback on this. They might see this as more work for them, but it might actually save time for both of you. They have a better understanding of the new API and it will be a quicker change for them to make. They already know what changed in the API and why, thus cutting down on cross team meetings and emails.

Make sure you identify their unstable API as a risk to the project as early as possible. Assess your options; determine if your schedule, budget, or scope for the project is at risk. Chasing a changing API never seems like a big deal to the project until it is too late. If it is not identified and dealt with early then it will put the whole project at risk for failure.

Negotiated Schedules Affect Quality and Deadlines

A while back I was at a meeting with a group of product managers from local software companies. The topic was the process of prioritizing requirements. When the estimated time of development came up, one product manager made the following comment:

“Estimates from engineers are always overestimated. They would want you to think all features would take about three years to develop. You need to negotiate the schedule.” …or something like that.

I could not believe what I was hearing. From my experience, engineers are usually over optimistic with their initial estimates. Only after thoroughly examining each essential step will an engineer increase their approximation to a more reasonable estimate. The fact of the mater is, software development efforts are notorious for delays and schedule overruns. This negotiation process is likely a common cause.

My guess is that this product manager probably feels a sense of accomplishment when the engineering team finally agrees to shorten their schedule. He probably then gets frustrated later when new releases are delayed. Product managers, project managers, program managers, and anyone else who has a say in persuading schedules must realize negotiating a development schedule does not mean the project will finish any earlier. The estimated delivery date is just that, an estimation. The actual delivery date will not be effected by the new estimations. It will not cause engineers to work any faster, it will not reduce the amount of work needed to be completed, and it definitely will not increase the number of hours in the day. The only thing a negotiated schedule will affect is a low quality product or a delayed delivery, and that is not something any manager should feel a sense of accomplishment about.

How Schedule "Should" Effect the Project Budget

Talking with a lot of project managers I find that many of them understand the challenges of the triple constraint. Schedule, budget, and scope all need to be tracked and managed. But, many of them do not understand the direct link between schedule and budget. Many project managers feel that a schedule slip is okay as long as the customer agrees to the delay or if there is no missed opportunity.

“We met with the customer and they understand the situation and have agreed to
move the expected delivery date out one year.”

Or

“Our competitors will not have these features in their product for
another two years. Even with a one year slip we will still be ahead of them by
six months.”

These points are valid points and the focus on the customer is very important when facing a potential schedule slip, but the financial implications for these delays need to be understood before moving forward with the new plan. Many times, delayed deliveries imply delayed revenue. Let’s say your customer has agreed to pay after the final delivery or sales are expected to start increasing after the new features have been added to the next release of the product. Even if the project has stayed within budget, the schedule slip might affect the success of the project in terms of the project’s net profits.

First, understand that a project is only undertaken when management feels the project will add value to the business (short-term or long-term). The completion of the project is expected to increase sales by 5% or the customer will pay $5 million for the final delivery. Schedule, costs, expected returns, and the required profits are all considered when calculating the success of the project. Changing the schedule will affect the required budget. A delayed schedule may require a smaller budget if for the project to still add value to the business. Take for example the following project.

A project is expected to last four years and is given a budget of $3.5 million over four years. The project will cost $120k in 2007, $1 millions in 2008 and in 2009, and $1.3 million in 2010. Added revenue is expected to be about $5 Million by the end of 2011.

Let’s say the cost of capital for the project is 15%. The expected Net Present Value (NPV) comes to $258,286. Great! A positive value means a positive growth for the business.


Now let’s say the project is expected to slip by one year. In most cases this would also impact the costs, but for this example we’ll assume the cost originally expected to occur in 2010 can be spread out over 2010 and 2011 ($700k in 2010 and $600k in 2011) thus keeping within the original $3.5 million budget.


This schedule slip changes the NPV to a loss of $63k! The project now reduces the value of the business!

What I want project managers to understand is that schedule is tied to the budget. Just because the customer is okay with your slip, you still need to make sure the project makes sense to the value of your business.

Exploration Efforts Still Need Project Management

A lot of projects start with a clear goal, an available budget, and the deadlines are already somewhat obvious. From my experience, companies are utilizing project management practices in these types of situations more and more. Companies are realizing that the execution of a clearly defined effort needs to balance the triple constraint of schedule, budget, and scope.

However, in my experience project management is not commonly utilized when the effort does not already have an obvious path and objective. An opportunity is understood to exist but the main tasks that need to be accomplished, the budget, and/or the schedule are unclear. In situations like this, companies tend to see the effort as an “exploration” and not a project. The “explorations” do not tend to follow any project management processes. This is a mistake. These efforts cost money, utilize resources, and tend to drag on without a final result. They end up adding no value to the company.

If you find yourself falling into this trap step back and think about why you are pursuing this ‘exploration” effort. In for-profit corporations, the end reason is for profit. You are pursuing this effort because there is some potential opportunity for your company to gain profits. Maybe you don’t have a clear understanding of the potential opportunity or how much it will cost. That is fine, but before starting the effort you need to at least come up with estimates. Determine what you are willing to spend for the estimation, decide what resources are qualified to complete the estimation, and give a deadline for the final estimation.

To complete your estimations, understand why you are investing in the effort. Get a good understanding of the opportunity and determine an estimate of the potential return. Estimate the window of opportunity you have or when the needed resource will be available to complete the effort. Deadlines will become more obvious and the project’s risks will become better understood (i.e. does the project that falls in line with your current business efforts). Next use your corporation’s financial structure to obtain the budget (if ‘x’ dollars are invested in this project over the life of the project and given the estimated return for this opportunity is ‘y’ dollars, our return will be a Net Present Value (NPV) of positive ‘z’ dollars).

The budget, schedule, and scope of all efforts need to be defined and project management is needed to manage the efforts. Understand and manage all efforts if you want them to be successful otherwise you are only wasting time and money.

Engineers know best - follow-up

A while back I wrote the post, Engineers know best. As a follow up to that post, it turns out I made the right decision. The engineer who had promised the completion of his tasks on time put in long hours and did in fact complete all of his work on time. This was the case of an engineer who wanted to complete his tasks and who knew the challenge ahead of him better than anyone else.

Similar to this common lesson is to listen when the engineer feels the assigned tasks cannot be completed in time. As a software engineer I was always able to complete my tasks on time-but the tasks were not always done right. When pushed to complete an unrealistic schedule, corners will get cut. These corners might not show on the surface, but under the hood the code might be an unmaintainable mess.

A quick YouTube video, “How developers fix bugs”, is a satirical explanation of how software developers can cut corners.



The lesson to learn here is an experienced engineer needs to be trusted when it comes to planning schedules. As a project manager we know project management, budgeting, resource management, customer requirements, and we might even have many years of engineering experience. But the engineer knows his or her skills, abilities, and the hidden coding obstacles he or she will need to overcome. Listen to your engineers and trust their recommendations. The success of your project’s success depends on it.

Testing Early and Often Can be a Wasted Effort

We have all heard the saying, "test early, test often" but in many software development efforts this can be a very costly mistake. It is imperative for software project managers to understand the full added cost each type of testing will have on the final delivery date. In many cases, it is the timing of when to write these tests that matter the most.

There are three levels of testing, unit testing, integration testing, and system testing. Integration testing and system testing are not as flexible, so I will not discuss these two efforts in this post. Unit testing does have some flexibility.

Unit testing is a required means to assure that the smallest possible elements have been tested. Unit testing is a required process in testing a system, no question. But the timing of these tests and the level of detailed required need to be considered. Writing highly detailed unit tests early in a project adds cost to the current development phase but, more importantly, adds cost to future phases as well. Maintaining these tests can be extremely time-consuming. In iterative process models, units are rewritten and redesigned over and over again. Each change to unit requires changes to the corresponding unit test. The more detailed the unit test the more time and effort required to maintain and update.

Project management needs to be aware of the added costs and implications to the project’s schedule. The nature of the project, the type of development process, and the size of the system being developed all need to be considered in deciding the unit testing level of detail and what phase or iteration these levels should be enforced.

Unit Testing Levels of Detail
First let’s clearly define each levels of testing. They are numbered and described below from the least complex level to the most complex.

1. Algorithm Accuracy testing
- Testing the accuracy of an algorithm. In object oriented languages, this is
testing the return of a method based on a few basic inputs.

2. Full statement testing
- Making sure the unit tests execute every line of code

3. Full branch testing
- All decision points (i.e. if statements) are executed for all outcomes

4. Every loop tested at 0,1 and many
- Testing each loop (i.e while and for loops) when the loop is executed more
than once at a time (many), only once (1), and when the condition of the loop
keeps the loop from executing its block of code at all (0)

5. Boundary value tests
- Testing boundary values for boundary condition statements (i.e. if(size > 0
&& size <= 10) Boundary value tests would test this statement when size equals -1, 0, 10, and 11 )

6. Full predicate testing
- Similar to level 2, Full branch testing, adding the requirement for each
condition for each predicate must be tested. (i.e if(boolOne == 1 &&
boolTwo == 2) Full predicate testing would tests all combinations when boolOne
equals 1 and does not equal 1 and boolTwo equals 2 and does not equal 2)

7. Path testing
- This level of testing implies all the previous levels but each branch, loop,
boundary, and predicate test must be done independently of the others.

Each level of detail adds more benefit to the reliability, accuracy, and even the complexity of the system. There is no question about this. Determining what level of detail is required by the stakeholders needs to be done regardless of the development process chosen, but understanding the cost of each level is important in estimating cost and schedule.

Software Development Processes
We’ll now describe the basic types of development processes. Depending on the project’s process, the costs of testing differ greatly.

Waterfall process – a sequential effort of phases (requirements analysis, design, implementation, testing (validation), integration, and maintenance). Each phase occurs only once. Traditionally, testing occurs once the implementation phase finishes but many times unit testing occurs during implementation. Either way, these efforts only occur once.

Iterative process – a non-sequential effort where phases can be revisited after there initial completion. A common iterative process, Agile process, comprises of short iterations. Each iteration visits or revisits each software phase. Think of an iteration as a small waterfall. Iterative processes reduce the level of risk to a project by giving the stakeholders of the project small releases of the product at the end of each iteration. The stakeholders are able to evaluate these releases and add feedback, suggest changes, and foster new ideas for the product. Stakeholders can better evaluate whether to continue on with the project or not. If continued, the project can redesign, and recode the product using the stakeholders’ feedback. This method ensures that the project and the stakeholders are communicating towards build a better product throughout the effort. This is contrary to the waterfall processes that only allow stakeholders to evaluate working examples of the final product at the very end of the effort.

If you are using the waterfall development process, once the implementation phase is done, you will not revisit this phase. Therefore, determining the cost attributed to each level of detail is simple. If an iterative process in being used, each level of detail will increase by a multiple of the iterations in the process. In many iterative development efforts, the code written in the first and even the second iterations will greatly change once the stakeholders give new feedback and make new requests. Writing highly detailed unit tests for these iterations will most likely be a wasted effort. Proceeding iterations will also have the added burden of editing and changing these tests.

Making sure these tests are written efficiently can cut down on the complexity and the level of effort needed to maintain these tests. Tools such as the Spring Framework can help to cut down drastically on the complexity of the setup code needed for each unit test and should always be used on medium and large efforts.

Levels of details such as levels 4, 5 and 6 should be post postponed until the system and software requirements have been mainly worked out. These levels add a large amount of extra code to the test suite. Not until the stakeholders seem to settle on the majority of requirements and details of the system should these levels of detail be added to the test suite. Although these tests greatly increase the quality of the software, their cost to write and maintain surpass their benefits to the early iterations.

Level 7, path testing, is a level of detail that adds great quality to a system, but it is extremely expensive. A testable section of code’s complexity can great affect the cost to create and maintain tests at this level. Some argue that requiring engineers to write full path tests influence engineers to keep the complexity at a minimum. I agree with this point, but in the early iterations of a development effort code complexity is irrelevant. These iterations are done to prove a concept to the stakeholders and to iron out the integration effort problems and system level issues. The last iterations before a system is released should be saved for this level of detail. The added costs in adding these tests to the system will be outweighed by the time and effort required to maintain these tests.

Conclusion
Every software project is unique and it is up to the management to understand the costs involved in each decision they make. Test adds quality but also adds cost. Test wisely adds quality but can reduce cost. As a project manager, make sure you understand the complexity your decisions add to future phases and iterations of the project. More detailed testing can be postponed until later interactions where there is less future maintenance needed to update the tests.

Engineers know best

In my current position, I switch from a project management role to a software engineering role depending on the project. Each project I get a different perspective of what is needed to make a project a success. This volley of perspectives, in my opinion, is making me a better manager than if I was no longer an engineer.

For example, a few months back I was acting as a software engineer. My job was to develop a utility component for a large planning system. The component was an HTN planner (http://en.wikipedia.org/wiki/Hierarchical_task_network) cool stuff! Anyways, with two months left before the project was due, I still had a lot of code left to write. The project lead at the time kept pushing me to delegate some of the work to another engineer as to assure that the development would finish on time. The problem was that all of the tasks that were left depended on the piece I was still working on. I couldn’t have someone else work on them because the code wasn’t ready yet. I was unable to explain this to the project lead and he assigned someone to those tasks anyways. The engineer now working on those tasks quickly realized he could not properly work on his assignment and decided to do the best he could. In the end, it actually took longer redoing his tasks. A few weekends and nights at the end of the project helped finish everything on time anyways.

Now I am acting on another project as the project lead. Last week we got word that the project’s due date has cut short by two weeks. It is up to me to figure out how to remove two weeks from the schedule and still complete all of the tasks. The two options for cutting back on a schedule are cutting the scope of the project or increasing the man power. Unfortunately, we cannot cut back on the scope. Given the nature of this effort, all pieces are absolutely required. The only thing left was to add more people. Using the cash reserve planned into the project, I am able to assign another engineer to the project.

I ended up asking one of the engineers to look over his tasks and look for something to carve out for someone else to work on. The reply, “sorry, there is no room on my tasks for someone else.” I looked as the description of the tasks he had again. It was the largest set of tasks on the project and it was on the critical path. It had to be broken up. I brought it up to another manager who had worked closely with this engineer a lot. He said he would talk to the engineer. Again the engineer would not change his mind.

Then it struck me. Here I am, doubting an engineer on his recommendations for the tasks that he knows more about than anyone else. He is a great engineer. Who am I to doubt him? He says he can get the work done quicker if needed but only if he is the only one working on that part of the code.

I have decided to trust the engineer and not assign anyone else to the project. I hope he is right.

UPDATE: See Engineers know best - follow up