IT Employment

General discussion


Development Schedule - No standard rules or measure to apply

By dilipj ·
While I observe that most developers breaking their head against the code, working late night and getting exhausted till the delivary time arrives, some teams are working in relaxed mode and they never miss schedule. They always deliver on time and are in very good relation with client and so on...

What can be the secret behind this...
- Uneducated client
- Smart Delivary/Project Manager
- Expert developers
- Excellent Scoping exercise
- smartly created schedule..

All DMs and PMs are always starving for the same I explained above...then..
Simply LUCK ..?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

a combination

by Jaqui In reply to Development Schedule - No ...

of things.
1) Correctly planned schedule for development.
2) A Coding Standard that works.
3) Programmers that have been smart enough to write portable code, or have a good knowledge of the code available to them for re-use.
4) A good team.

on point 1, sales team, and develpment team have to work together to come up with a delivery schedule that the customer can live with, the development team has to be involved in the requirements discussions in some fashion, to be able to give reasonable estimate of development time.

on point 2, the simplest way to set a coding standard: use the international standard for the language ie: ansi c / C++. clearly define what is meant by well documented / commented code. the coding Requirement for the company should be detailed in the documentation / commenting area, in clear, plain english [ or whichever language is used in workplace ] no legalese.

on point 3, every function that they write can be coded where it will only ever work in the software they wrote it for, or it can be coded to be re-used in projects that it will help later on in their career. If a programmer is not familiar with the libraries of code that are available to them in the workplace, then they will often be slower developing new software, as they are constantly writing new code that already exists.

on point 4, the entire company has to be a team, from every department, if there is anyone who doesn't feel that the company is a team then they are not as productive as they can be. This includes Management. the Sales rep that got the contract for the product is a part of the development team, they are the interface between the developers and the customer, their job has not ended until the customer has received exactly what they ordered.

Collapse -

When it all comes down to this

by mjd420nova In reply to Development Schedule - No ...

ATITUDE If you have a happy work place SO'S
THE BANK. When you give employees the power
and resourses to accomplish their goals,
the sky's the limit. You only get out what
you put into project, plus that added amount
you have garnered along the way. REPUTATION
can go a long way and RUMORS will get you

Collapse -

Project Management Processes

by BFilmFan In reply to Development Schedule - No ...

As with any effort in life, some people unsderstand the difference between management of a process and being a figurehead.

Successful teams tend to have leader/coaches/mentors who are part of the effort who understand the process and are able to deliver.

Collapse -

As others have said

by JamesRL In reply to Development Schedule - No ...

Its a combination of factors.

Sometimes you have to slow down to speed up.....

What I mean by that is that the more thorough and painstaking a process you have for developing thorough requirements, and creating a realistic project plan, the more likely you are to deliver on time without the kind of stress you describe.

What often derails development projects are additional requirements which pop up once development has started, or bad assumptions on technical issues which lead to a dead end. The more time you spend up front, the less likely these are to happen.


Collapse -

Yes, formal project planning and estimating

by DC Guy In reply to As others have said

I was beginning to wonder if it was still 1975 until I saw James's post.

How long has this organization been building software? How many statistical data points should they have by now showing staff-hours per Function Point delivered?

You say they're not measuring software functional size by counting Function Points? Never even heard of them? Well, you can't manage what you don't measure, as one wise person once said and many others have since quoted.

You say there's no point in looking at the time records because they show that everybody worked 40 hours every week? Well, this really is the Bronze Age then, isn't it.

If you don't measure what you build and you don't keep honest records of how much labor it takes to build it, how the heck are you going to estimate how much labor it will take to complete your next project?

You say they don't do formal project estimates? No top-down, bottom-up, parametric, Delphi, or any of the half dozen other ways I teach in my project management classes? The customer told the salesman that he needs it by July 31 and he's only willing to pay for 12 staff-months of labor, so that's the way you agreed to do it? I take it back then, it's the Stone Age.

Welcome to the 21st Century.

1. Implement software measurement.
2. Switch to honest timekeeping.
3. Make project estimation a formal step in every project.
4. Stop letting salesmen run the company.

Collapse -

Lot's of reasons

by Tony Hopkinson In reply to Development Schedule - No ...

The big one for me is the finite size of a piece of A4 paper.

What is this guy on about ?

Very simple, your project is going to be a disaster are if.
More stuff gets added but the resource stays the same.
The initial estimate of the required resource was considered too expensive, so some idiot agreed that it had been overestimated.
The estimates were not done by the people who had to do the work
Someone says half way through the project, you never said this wasn't in scope or
oh by the way, make it do this as well.

Developer's do not have psychic gifts, nor did they qualify for magic school, so relying on them guessing what you really wanted or pulling a tenner from behind your ear might not be a wise move.

I see it time after time. Nice plan composed by a set of business management types, fits beautifully on a piece of A4 and will always do so no matter what!

No plan will survive contact with reality to paraphrase someone who knew how to organise his sh1t.

Collapse -

Textbook case of "no-brainer"

by DC Guy In reply to Lot's of reasons

"The estimates were not done by the people who had to do the work."

That is one of America's biggest project killers, yet it's also one of America's favorite project management tactics.

Every project estimate MUST have at least two components:

1. Top-down, which is the project manager's estimate. Typically this is itemized by type of resource (business analyst, DBA, programmer, tester, etc.) and number of hours per month for each. But it can be anything that reflects the manager's decomposition of the project.

2. Bottom-up, which is the project staff's estimate. Typically this is itemized by task and total hours for each, but again it's ok as long as it's logical. Each staff member can do his own, which are then combined, or they can work on it as a team.

Who are the people who really have the best information regarding how long it takes to do something? The people who do this kind of work for a living: the manager and the staff! If the person who is planning the project doesn't get THEIR input, then you've found the "idiot" referred to in the previous sentence. This is a textbook case of a "no-brainer," so anyone who hasn't figured it out really has "no brain."

Collapse -

Well the place

by Tony Hopkinson In reply to Textbook case of "no-brai ...

I'm at now doesn't make that particular mistake unfortunately the code base is now rather old, the design badly out of date and there's been no refactoring for a long time, so even our most conservative estimates can come up badly short.
In one case it actually took me four hours to change the text colour of a label component. The code is shockingly bad, you could give it to a set of students as a learning exercise, I don't think there's an example of how not to do something missing in it. Course now we over-estimate out of fear that it will **** up on us, which of course scares the **** out of management. The case for a re-write is looking pretty strong in cold hard beancounter type numbers, now.
I'm thirsting to be on with it, but as usual, got to have a lot of meetings and get buy in to spread the blame out.

Related Discussions

Related Forums