Iyfjky

Question

I am looking for project management techniques and tools to help with the following situation.

(P.S. I know this question is technically off-topic but I felt Revisiting Tool Recommendation Questions expressed a degree of leeway. I am new to project management. I'm sure the community has a lot of useful advice for me.)

We are doing a software development project for a client which has a fixed budget (about USD 100k) and fixed time (about 6 months). I have a team of developers working on it. The requirements are clear (and I've worked with this client many times before so I don't predict big problems there.)

My question is, how can I keep this project on track in terms of time and budget? (If I go over budget then that'll be very frustrating, despite all the work we're going to put into the project, it would make more sense for me to fire everyone and just sit in Starbucks all day... I really want to avoid that!!)

I'm thinking, you can't change the past, but you can change the future. So I need to keep a track on the costs that have happened, and the predicted costs and effort in the future. And keep a constant eye on whether we're predicted to hit the time and budget constraints, and if not, try to take action. The sooner I know the more chance there is of being able to correct course; if I find out the night before the deadline we're not going to make it, it's too late to correct it.

Here's what I've considered:

Scrum. Dividing the project up into sprints. But, because I know what all the sprints are going to contain ahead of time, it's not really "agile". Is this a good/useful option?

Use a tool such as MS Project Online, LiquidPlanner or similar, to enter all tasks and estimates. Team knows what to do, team updates estimates and tasks as soon as things change. I keep a constant eye on spent budget, predicted budget, predicted delivery date. Which tools should I look at there?

Use an offline tool such as Excel or MS Project (offline). And have weekly status meetings where everyone has to update me. I have the worry that then I'll be a week behind (e.g. I've literally seen such situations; have the meeting Monday morning, on Monday afternoon a big problem is discovered, the plan is out-of-date until the next Monday, a week is lost during which preventive action could be taken). Plus nobody likes those big status meetings. Plus they cost a lot.

Bonus features I'd love:

Handling uncertainty somehow, e.g. a screen in the framework we already know can be predicted reasonably accurately, a piece of research less so. Ideally "min 0.5 days, expected 1 day, max 5 days" or something.

Real world estimates such as "1 day of effort" as opposed to "7 story points"

I don't have to spend ages moving Gantt bar charts around the place. Ideally I say "this takes 1 week of effort, and can't be started before this other task finishes, and this person is on holiday on those weeks" and the tool tells me if it'll be done by the deadline or not.

Dependencies, critical path analysis, so I know which work to look at in case we're not going to meet the deadline.

Display of how long people have got work for e.g. "Bob runs out of work in 2 weeks, Joe in 3 months", so I can decide who should take on new tasks.

"what if analysis" like "if I add another developer to the team, will it help the deadline, assuming we have to train them, and maybe development isn't on the critical path"?

Ideally web based. Not PC/Mac based; so it's cross-platform for my team, and ideally not paper-based to support people who aren't always working from the office.

Generate reports with nice KPIs such as what % of the project we're through to present to the client. (Nice to have)

Tool is not slow and difficult to use and annoying. (Nice to have)

I don't mind about cost, if I can avoid a financial disaster with this project then I'm happy to pay for it!

EDIT/ADDITION:

Thanks to Erik for the question "What kind of action are you going to try and take, if the project has fixed budget, fixed time, and fixed scope?" Here's what I was thinking:

I can ask the client for more time. It might be OK for the client or it might not be but it's worth asking. It's never ideal to ask for more time, but if I have a 6 month project and I ask for 2 extra weeks in the middle, I think it sounds more professional than if I ask for those 2 extra weeks the night before the deadline. And if the client is doing marketing activities based around the deadline, it might really be no problem to postpone them 4 months before the deadline, but be a real problem to postpone them if you let them know a few weeks before the deadline.

I can ask the client for more budget, or to reduce scope. Again, far from ideal! But I've done it, and it does sometimes work. Again, doing it with months still to go allows for a better conversation with the client than the night before the deadline, where some of the features the client might offer to drop have already been developed (so dropping them would now no longer help).

Reduce exploratory work. Maybe the team is spending time exploring new technologies (e.g. new software frameworks or whatever). Such things can help the project, or not, one doesn't know at the start, if they're time they're definitely worth investigating. I can terminate such activity and assert we'll use technologies we already know. (This example comes from my actual experience.)

Potentially put other people on the project, if it's just a question of time and not cost. Always a risky move. But, at least it's an option if there are months still to go. It's not an option if there's only two weeks to go. Better to know about the problem sooner than later.

Discovering risks as soon as possible seems to make sense to me. You're going to make better decisions the more information you have (i.e. it's better to know it's going wrong 2 weeks in, than not to know.)

What kind of action are you going to try and take, if the project has fixed budget, fixed time, and fixed scope? — Aug 13 at 11:37
@Erik - Thanks for your question, I have added a section to the question with the answer. — Aug 13 at 14:18
Who bring up the 6 months? Is the fixed time and budget reasonable(for you and your team)? How good do you know the development team? — Aug 14 at 5:28

Mark C. Wallace 5,64721934 · Answer 1 · 2018-08-13 11:51:53Z

@DavidEspina has it right - I'd like to add a few thoughts

This question illustrates one of the reasons tool recommendations are out of scope - CodeGnome's law says you need to decide how to solve the problem before you look for a tool. You haven't yet defined your problem, so no tool can help; tools are more likely to obfuscate the problem by providing illusory solutions.

You're looking for a way to manage a project without risk. Risk management is project management. If you bid the project such that you cannot accommodate variations in production speed, unexpected problems, etc, then that is the definition of your problem, and no tool can help. The normal practice is to bid the project with a management reserve to help you to deal with risk.

How do you keep the project on track? The traditional way is Earned Value Management, but EVM requires some advance planning to define the work you're going to expect to get done. You can avoid the status meetings by designing your work packages with good metrics that are objective, but don't require a prolonged status meeting. Software development is difficult in EVM.

I don't know whether you intend it, but the subtext of all of your bullets is, "I want simple methods to manage a complex problem". That makes me somewhat suspicious of the whole situation.

Sarov 7,55821436 · Answer 2 · 2018-08-13 15:06:05Z

Basically if anything does not go according to plan you are screwed. The problem is that you promised to deliver fixed features (scope) for a fixed budget (resources) before a fixed deadline (schedule).

Scope, resources and schedule define what is called the iron triangle of software development. The idea is that if you change one side of the triangle, the other sides have to give.

For example, if a feature that was agreed on is more complicated to develop than originally estimated, you can either remove another feature to make up for it, or push back the deadline, or add more resources (developers).

But if you are not allowed to change any of scope, resources and schedule, you have no way to compensate (other than delivering sub-par quality) and the project will fail.

If you do not adjust one of the three sides, the only thing left to adjust is the quality of the resulting product. Low quality will show up as shortcuts ("quick 'n dirty") that have been taken and technical dept that has accumulated. The concentration of your developers will also suffer if they work to much overtime, causing bugs. Any technical dept will make maintenance and implementing new features harder and more time consuming further down the road, and should be factored into future estimates. Also note that fixing a bug that is already deployed to production is much more expensive to fix than during development, so taking shortcuts in quality assurance is a bad/expensive idea.

What I would recommend is to work with the customer to prioritize the features into "must have" and "nice to have", with the understanding that you are allowed to move the "nice to haves" to a later release if you are running out of time. The reasoning here is that it is better to have a working software with satisfying quality, albeit less features, than no software at all. Be careful here, many customers do not really known what they want. A good requirements engineer should be able to tease out which features actually provide added value for the daily work of the employees of the customer.

Ã¢Â€ÂœIf I had asked people what they wanted, they would have said faster horses.Ã¢Â€Â - Henry Ford

Scrum can be your friend here, if you are able to get the customer on your side. The advantage is that the customer gets regular feedback (maybe even a working prototype) after every sprint, so he will be less surprised if a deadline can not be met. Prioritizing the features can also be handled in a transparent way (let the customer suggest which features are the most important ones by setting the business value of the backlog items).

Further reading: The "Broken Iron Triangle" Software Development Anti-pattern.

David Espina 29.4k32278 · Answer 3 · 2018-08-13 09:54:52Z

There is no tool or technique that will guarantee you will come in on time and within budget. Work is probabilistic. If you need more certainty, such as you don't have the funds to pay for overruns, then your only option is to bid a lot of fat. Bid in the 80th or 90th percentile of your estimate for both time and money.

You won't win the work but, if you did, it is pretty unlikely you'd overrun except for some pretty significant malpractice.

Or bid another contact like T&M or CP.

Sarov 7,55821436 · Answer 4 · 2018-08-13 13:49:06Z

I agree with everything David and Mark have said. Further, I'd just like to comment on:

But, because I know what all the sprints are going to contain ahead of time, it's not really "agile".

How can you possibly be sure that you know what it is ahead of time?

Are you 100% certain that you have made absolutely zero mistakes gathering the requirements? That the client made zero mistakes presenting the requirements? That the client won't change his/her/its mind? That the requirements have been documented/articulated such that they can be interpreted perfectly correctly? That there's no chance a developer or analyst will discover a better approach that the client prefers? That there is absolutely no chance of the market changing during the project? What about new technologies? Internal process improvements? Just about any other environment variables?

If you really are 100% certain of the above, then why not just outsource some cheap labour? It's not like building such a product should require much thinking or communication, anyway. Just show them your stone-tablet containing the project spec and let them work.

If, however, there is uncertainty, then agile becomes a viable method after all. Whether or not it's the best method is a matter for debate and outside the scope of this Answer.

Sarov 7,55821436 · Answer 5 · 2018-08-13 16:52:57Z

This will not be a full answer to your question, but it contains one important piece of the puzzle if you ask me. Getting projects out of the door is very much about risk management. In my experience risk management is about two things:

Finding the important risks

Mitigating where possible

Of course, if the project has too large scope, too little resources and too short time schedule then right now is the time to find out about that. But if you still believe that it is possible to deliver within the limitations, now is the time to find the largest risks.

One simple technique is to do a risk calculation every week. Include a group of people, spend at maximum an hour.

What can happen?

How large of an effect will it have on the desired outcome?

How large is the probability that it will happen?

Assign arbitrary levels 1-5 on effect and 1-5 on probability. Multiply risk x probability and you know which risks to start to work with. Put the result up on the project whiteboard and talk briefly about it during the morning stand-up meeting. Hopefully, next week the list will be different.

One thing to look for is to remove the tail-end risks early. Things like "performance will not be sufficient" when found at the end of the project will cost a lot more to fix than if found in the beginning. If you are uncertain, do a quick-and-dirty simulation testing exactly this area. (But only if it is an important risk).

Good luck! Sounds like you will need a bit of that as well.

score 1 · Answer 6 · 2018-08-15 03:57:39Z

As some other answers already pointed out no PM tool will guarantee success. Anyway, letÃ¢Â€Â™s take a look of your options.

As you mentioned Scrum, it seems that your not only looking for PM tool more you are also looking for a (development) framework/process. First of all if your team doesnÃ¢Â€Â™t have already established a well working process then introducing a new one to a project with short/fixed time/budget is a huge risk.

However, basically there are two models of (development) processes: waterfall and iterative and incremental / agile. Both have there pros and cons.

Waterfall
If your project is a no-brainer, your requirements are clear and will not change over the time, the overall risk of unexpected things is very low, your team is functional orientated (analyst, designer, developer, tester, ...) then this model might be a solution.
As I wrote, this model is only recommended for no-brainers because it has some serious drawbacks when your requirements are changing or something not expected is happening (as in most projects). In such cases this model leads to higher costs, late deliveries and customer displeasure.

Iterative and Incremental / Agile
If your project is complex, the requirements are unclear, your team is cross-functional, the risk of unexpected things to happen is high then this model might be an option.
Although this model is more suitable for most (software) projects it has an higher complexity, demands higher expectations from all team members (and stakeholders) and might produces more overhead.

You mentioned you are considering to use Scrum. It is a complex agile model with certain roles and events which leads to a lot of overhead. I donÃ¢Â€Â™t think that you have the time to establish and to work by Scrum especially if your time frame is fixed. Of course there is always the possibility of tailoring Scrum (adapt it to your needs) but if your are not experienced and this project is your pilot then this will be another huge risk. Also Scrum is a framework which is perfectly suited for product development (on-going), for projects which are very unclear and where the time to market is crucial.

Beside Scrum there are a lot of other incremental and iterative / agile frameworks/processes like Kanban, Lean, XP. Some of them produces less overhead, are less complex and less strict.

So before you decide which PM tool you have to decide which working process you want to establish. And this depends on your project, requirements, team, experience, company etc.

Some final thoughts, at the end it really doesnÃ¢Â€Â™t matter if you are using Excel, MSProject, Trello, JIRA etc. you should take care first about your process.

Mark C. Wallace 5,64721934 · Answer 7 · 2018-08-13 11:51:53Z

@DavidEspina has it right - I'd like to add a few thoughts

This question illustrates one of the reasons tool recommendations are out of scope - CodeGnome's law says you need to decide how to solve the problem before you look for a tool. You haven't yet defined your problem, so no tool can help; tools are more likely to obfuscate the problem by providing illusory solutions.

You're looking for a way to manage a project without risk. Risk management is project management. If you bid the project such that you cannot accommodate variations in production speed, unexpected problems, etc, then that is the definition of your problem, and no tool can help. The normal practice is to bid the project with a management reserve to help you to deal with risk.

How do you keep the project on track? The traditional way is Earned Value Management, but EVM requires some advance planning to define the work you're going to expect to get done. You can avoid the status meetings by designing your work packages with good metrics that are objective, but don't require a prolonged status meeting. Software development is difficult in EVM.

I don't know whether you intend it, but the subtext of all of your bullets is, "I want simple methods to manage a complex problem". That makes me somewhat suspicious of the whole situation.

Sarov 7,55821436 · Answer 8 · 2018-08-13 15:06:05Z

Basically if anything does not go according to plan you are screwed. The problem is that you promised to deliver fixed features (scope) for a fixed budget (resources) before a fixed deadline (schedule).

Scope, resources and schedule define what is called the iron triangle of software development. The idea is that if you change one side of the triangle, the other sides have to give.

For example, if a feature that was agreed on is more complicated to develop than originally estimated, you can either remove another feature to make up for it, or push back the deadline, or add more resources (developers).

But if you are not allowed to change any of scope, resources and schedule, you have no way to compensate (other than delivering sub-par quality) and the project will fail.

If you do not adjust one of the three sides, the only thing left to adjust is the quality of the resulting product. Low quality will show up as shortcuts ("quick 'n dirty") that have been taken and technical dept that has accumulated. The concentration of your developers will also suffer if they work to much overtime, causing bugs. Any technical dept will make maintenance and implementing new features harder and more time consuming further down the road, and should be factored into future estimates. Also note that fixing a bug that is already deployed to production is much more expensive to fix than during development, so taking shortcuts in quality assurance is a bad/expensive idea.

What I would recommend is to work with the customer to prioritize the features into "must have" and "nice to have", with the understanding that you are allowed to move the "nice to haves" to a later release if you are running out of time. The reasoning here is that it is better to have a working software with satisfying quality, albeit less features, than no software at all. Be careful here, many customers do not really known what they want. A good requirements engineer should be able to tease out which features actually provide added value for the daily work of the employees of the customer.

Ã¢Â€ÂœIf I had asked people what they wanted, they would have said faster horses.Ã¢Â€Â - Henry Ford

Scrum can be your friend here, if you are able to get the customer on your side. The advantage is that the customer gets regular feedback (maybe even a working prototype) after every sprint, so he will be less surprised if a deadline can not be met. Prioritizing the features can also be handled in a transparent way (let the customer suggest which features are the most important ones by setting the business value of the backlog items).

Further reading: The "Broken Iron Triangle" Software Development Anti-pattern.

David Espina 29.4k32278 · Answer 9 · 2018-08-13 09:54:52Z

There is no tool or technique that will guarantee you will come in on time and within budget. Work is probabilistic. If you need more certainty, such as you don't have the funds to pay for overruns, then your only option is to bid a lot of fat. Bid in the 80th or 90th percentile of your estimate for both time and money.

You won't win the work but, if you did, it is pretty unlikely you'd overrun except for some pretty significant malpractice.

Or bid another contact like T&M or CP.

Sarov 7,55821436 · Answer 10 · 2018-08-13 13:49:06Z

I agree with everything David and Mark have said. Further, I'd just like to comment on:

But, because I know what all the sprints are going to contain ahead of time, it's not really "agile".

How can you possibly be sure that you know what it is ahead of time?

Are you 100% certain that you have made absolutely zero mistakes gathering the requirements? That the client made zero mistakes presenting the requirements? That the client won't change his/her/its mind? That the requirements have been documented/articulated such that they can be interpreted perfectly correctly? That there's no chance a developer or analyst will discover a better approach that the client prefers? That there is absolutely no chance of the market changing during the project? What about new technologies? Internal process improvements? Just about any other environment variables?

If you really are 100% certain of the above, then why not just outsource some cheap labour? It's not like building such a product should require much thinking or communication, anyway. Just show them your stone-tablet containing the project spec and let them work.

If, however, there is uncertainty, then agile becomes a viable method after all. Whether or not it's the best method is a matter for debate and outside the scope of this Answer.

Sarov 7,55821436 · Answer 11 · 2018-08-13 16:52:57Z

This will not be a full answer to your question, but it contains one important piece of the puzzle if you ask me. Getting projects out of the door is very much about risk management. In my experience risk management is about two things:

Finding the important risks

Mitigating where possible

Of course, if the project has too large scope, too little resources and too short time schedule then right now is the time to find out about that. But if you still believe that it is possible to deliver within the limitations, now is the time to find the largest risks.

One simple technique is to do a risk calculation every week. Include a group of people, spend at maximum an hour.

What can happen?

How large of an effect will it have on the desired outcome?

How large is the probability that it will happen?

Assign arbitrary levels 1-5 on effect and 1-5 on probability. Multiply risk x probability and you know which risks to start to work with. Put the result up on the project whiteboard and talk briefly about it during the morning stand-up meeting. Hopefully, next week the list will be different.

One thing to look for is to remove the tail-end risks early. Things like "performance will not be sufficient" when found at the end of the project will cost a lot more to fix than if found in the beginning. If you are uncertain, do a quick-and-dirty simulation testing exactly this area. (But only if it is an important risk).

Good luck! Sounds like you will need a bit of that as well.

score 1 · Answer 12 · 2018-08-15 03:57:39Z