Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Software development

Is ‘No Estimates’ for real?


No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.

Is No Estimation for real

When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.

I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to  be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.

Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.

From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.

In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.

Image Credit: Dilbert (Scott Adams)

Understanding your people


You read many different topics on project management, but very few to do with understanding the people that work with you. I had previously posted about some of the lessons I took away from an industrial psychology session. I recently had a conversation with someone regarding why those sort of approaches are necessary when you are dealing with adults.

The key thing is, as project management professionals, we can bring to the table many good methodologies, experiences and tools. Ultimately it is what output we can get from our teams that translate into success and failure for our projects. It is therefore as much an art, as it is methodologies, experiences and tools. Even though I come from a software development background, I have not personally written code for many years. As such I know the concepts of what forms good deliveries and have understanding of many of the pitfalls. However, this is a rapidly changing field with significant paradigm shifts in design and delivery considerations. I rely on the developers in the team to advise on the most suitable approaches to work at hand.

Like any other profession, developers come with many different idiosyncrasies. Some are good talkers and as a result can manipulate discussion time; others are thinkers that give the impression they do not care, but in reality that is their thinking face; and there are those that are very skilled but shy and reluctant to put their ideas across. I consider it my responsibility to understand their tendencies and bring all of their strengths to the table. All of the team will have some strength and some areas that can be worked on. Some of the areas can be supplemented by repeatable processes or training. There are areas where the only way to move forward is through encouragement and building a closer relationship with people.

It is always a challenge when you join a new organisation. Understanding people and their tendencies is not something that you can do in a short time. You may be able to get an initial impression early on, but must keep an open mind and refine your thinking as you go. Building a trusting relationship is also takes just as much time. It is a two-way street. While you are trying to understand how best to maximise output from your people, they too are trying to understand how they can work with you. If you are able to understand their point of view quicker, your chances of success go up.

It is not a matter just treating them as adults and telling people to get hard. Best outputs are always in environments that are most enjoyable to work in.

Image credit: NY State University

How does organisational growth impact project delivery?


Delivering projects is more than simply tasks undertaken to get something out of the door. Inevitably, how a project is delivered is dictated by the culture of the organisation. I work for a niche technology solution provider that has undergone nearly four-fold expansion since I joined six years ago. I have been thinking how that has changed our project delivery. Many of the analogies I draw will be familiar to you if you have read Frederick P Books Jr, the father of IBM System/360.

As a small company, we worked on small projects – mostly using one or two resources. Because of the size of work we could take in, there was a natural limit to risk we were exposed to. It is easy to communicate between two or three people by simply sitting next to each other. Even informal communication is sufficient to set goals, share designs, report progress and quality control each others’ work. Because the work packets are small, it is also easier to slot them in based on project timeline commitments. We managed to get a phenomenal productivity out of our staff.

As the company started growing, the work packets started getting larger. We were able to take on more complex work. Goals that a project manager could explain to two developers, now need considerable documentation. He cannot now sit next to all the team and fill in the gaps if something comes to light. As growth continued, there was need for more project managers. This creates more challenges, as now all the project managers have to align their processes to ensure projects are delivered in a uniform way. Slowly, but surely, the productivity achieved in the early days becomes difficult to sustain.

The staff we have are of exceptional calibre. So why the impact on productivity? The key here is the the overhead of communication. The original scenario I described is what Brooks calls the duo working out of a garage producing software that far exceeds big teams. However, there is a certain size of software you can produce with that capacity. In order to deliver something more complex with the two same developers, it will take so long it will not be worth pursuing. The only answer here is to add more people. As soon as you do that, it creates the productivity issues I talked about previously.

A simple mathematics shows the impact. The communication channels in your project team is n(n-1)/2. In a team of 2, there is only a single line of communication. Team of 3, makes it 3, 4 makes it 6. As you can see, More people you want to herd to the same goal, your communication effort multiplies exponentially. Military works by asking no questions. So one may ask why not follow that model. Most of your development team are usually from the opposite end of the IQ spectrum to that of your privates. Persuasion is your best ally here.

This clearly shows that more complex the delivery, and more people are required, software development itself becomes less of the overall effort. Ensuring the team works well, everyone knows what they are required to achieve, outputs are tested for their fit for purpose and efforts are targeted correctly to achieve the goal that has been set out requires considerable dedication.

Many a time reaction from management or clients is to throw more resource at it and expect output to increase in a linear fashion to the number of resources added. That may be achievable in fruit picking, or office cleaning, not in software development. It also does not take into account some tasks take a certain duration. No amount of resources will deliver an early output. I love Brooks’ analogy here … Bearing of a child takes nine months, no matter how many women are assigned.

Have you been growing recently? I would love to hear your experience.

Is Agile for me?


If you talk to any project team, you will find varying range of opinions regarding the best methodology for development – all very passionately putting their points of view across. Barring the occasional accident, most of these teams have given considerable thought to what is most applicable to them and have followed that course. When each of them argue in favor of a different methodology, it is well founded in facts. However, the one thing that is missed in all these discussions is that the challenges facing all the different teams are not the same. Let us consider various scenarios.

Follow this scenario … an organization realizes the need for a new system. They go through an internal requirements gathering process and invite tenders for the system, to be implemented by a certain date. You are a professional services organization. You are required to estimate the effort required to design and implement the system. In your response, you have to provide a price, as that would undoubtably be one of the selection criteria. You happen to win the tender. What is your status? You are now locked into a fixed deliverable to the client, to be completed by a date within a cost you have specified. Is there any room for agility? When you think about the triangle of constraints, effectively you can move none.

You can legitimately ask why not estimate to do the work following Agile principles, that would solve this dilemma. Let us then review how business is done in the real world. For all of us IT professionals that like to think we’re God’s gift to mankind :o), the reality is that we’re a support cast in most organizations, that only utilize IT as a means to achieving their business goals. In business, everything is driven by supply and demand. Think of it this way … if you bought something from a store, you may be able to take it back and get something else that is in a slightly different color, or size. However, if you ordered something custom to be made, and then changed your mind on the size, would you expect that to be accommodated? This is the difference between a product sale and custom work. Software development is no different.

When you are developing a product, or are in a development or support team within the organization, you have a steady commitment to resources. You have the ability to select your sprint schedule. Your costs are also therefore fixed. You have some leeway on scope. In such scenarios the organization has already accepted the cost of this continued effort and therefore scrutiny on the resources (and by extension cost) is not the same. The scrutiny is likely to be more along the lines of value for money … is the overhead we have agreed to getting us the improvements (or new functionalities if it is a product development) we’re after.

Custom development is an entirely different beast. Here uncertainty reigns. Most likely reason the organization is getting you to do the project is they do not have the resources or capability to do it themselves. At the same time many of the users will also not have the understanding of what is possible to achieve. In such scenarios you will end up spending significant effort in communicating possibilities and success criteria for your work to be accepted. Encouraging change of requirements, even at late stages like Agile methodologies will ensure you never come in on budget or are forever locked into a change control battle.

The second key when considering using Agile methodologies is the likely size of the project team. In essence the Agile teams are self organizing teams that work based on a given set of requirements and set their own schedule. The emphasis is on responding to change over following a plan. This works really well and reduces overheads. However, this is only true for a small team. When the team size goes to beyond six or seven, this becomes more and more difficult. Adding each new team member adds many new lines of communication necessary to keep this self-organization working efficiently. Bigger the team lesser the chance of success using Agile methodologies.

If you have been landed with an Agile project because no-one knows the requirements, think again. That is a guarantee for chaos. Agile is not a substitute for requirements gathering. In fact, Agile requires a continued emphasis on requirements through product backlogs and user stories. There is a constant requirement to refine user stories, even for items that do not make it to the current sprint. Many a time customers will not object to time spent writing code and testing it. They will object to this continuous refinement and management efforts. Before you jump in, consider if your client is inclined this way.

Does this mean that you cannot use Agile principles at all in some of these scenarios? No, that is not necessarily the case. You can use Agile principles in your teams, but will most likely struggle to run the entire project using Agile practices. You will need something overarching to ensure adequate control and communication. Agile is best suited for product development and in-house support teams.

What do I do in a failing project


I was reading a report from Keith Ellis from IAG Consulting that only one in three software development projects in the US actually makes it to completion. Larger the organisation, higher the chance of cancellation. Regardless of the reasons behind the cancellations, it means as a project manager, time will come when you will have to deal with a project that is headed south. What do you do when you find yourself in such a scenario?

In my experience, the first casualty of any project going in the wrong direction is documentation. This is the most fatal mistake of all if done with project management artefacts. Once things start going downhill, you as the project manager is the one under the gun, regardless of reasons. You are the easiest scapegoat.

The only way to protect yourself is to ensure that you capture all decisions made in the project. The odds are, many of them will have been made by people under or over you, for operational and strategic decision. While you can influence decisions made by people under you, you may or may not have decisions coming from above you. Get into the habit of building a dashboard early in the project and update each week with actuals. Use a standard repeatable technique to analyse the health of your project. I use the Earned Value Analysis technique. Use something that you trust.

If you are in a project where resources are contested, clearly outline the resources that you require to deliver within the tolerances afforded to you in terms of time, scope, budget, risk, quality etc. If resources are pulled from your project, clearly articulate the affect of that in delivery terms. Measure that to time delayed or cost added. I find if you can equate it to a dollar value, it clearly gets the attention of management.

Run a strong and vigilant risk and issue register. Make it visible and encourage your team to actively participate in it. In my view lack of focus in this area is usually a cause of many projects sinking. While you cannot foresee every risk, a good project culture will ensure your team will pick up more than you think.

Remember, cancelling the project is not always a failure. There can be many reasons why the project may no longer be desirable now. Things may have changed from when the project started. If you have done your job well, you can be really successful by ensuring a project does not continue to meander along, wasting time and money when there is no possibility of achieving the benefits it was conceived to achieve.

Big obvious cock-ups will claim its victims in spectacular fashion. Those are highly visible and unlikely to take your scalp. It is the slow bleeds that you need to prevent. No one remembers those and when a scapegoat is required, you’ll be wearing the cross-hair.

%d bloggers like this: