IT Employment

General discussion


Process and methods

By CBV ·
Hello everyone,

I have to manage a quite important and large software project. The problem is that we don't have a development process and methodologies put into place at company level, it's a new development team (11 people) where almost everyone is still a student so they don't have much experience in working in a professional manner. So some of the programmers have such experience but most of them don't.
What I would like to do is to get the people to learn these things. I was thinking about combining some things from Rational Unified Process and Catalysis. I have knowledge about RUP and some of the developers about Catalysis.
I would like to know if anyone out there was in a similar position where he or she was supposed to come up with some standards at company level like I'm supposed to do now.
I really could use some help on this.

Thank you very much!

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Try Tenstep project methodology

by prj_mngr In reply to Process and methods

Take a look at for things that you should be doing in managing a development project.

Collapse -

Contact ME for "Reality Based" help

by kprivette00 In reply to Process and methods

E-mail me at I then can give you my phone number and we can discuss face to face. I have lots of ideas that will !!!!really!!!! help.

The biggest things you have to do is train the methodology and process then apply to a pilot project with industry experts. This is what I will would like to discuss. Many so called experts in these two methodologies have given it a bad name. You can get an honest no sales pitch real world "reality" based help!

Collapse -

You certainly could

by Tony Hopkinson In reply to Process and methods

sounds like a recipe for a disaster.
Couldn't even comment on the best methodology to use, because I don't know what your project is. Personally I'd recomend you get an experienced consultant in for a few months to set you on the right path. The expense will be more than worth it. Most of it is common sense though. Can you bite off a useful chunk of the big project for at least part of the team (preferably most of the experienced ones) to work up a system and iron out the rough bits?

Collapse -

Some practical advice

by DC Guy In reply to Process and methods

Two things that American IT project managers hate to do, and as a result the industry is migrating offshore:

1. Requirements inspection. The most expensive, ruinous, and unrecoverable project failures are almost always due to defects in the requirements. Testing doesn't catch them because guess what the testers test against? All it takes is someone who is reasonably familiar with the line of business and someone who is reasonably familiar with the technology to sit down together and read the requirements. They won't find the subtle errors but it's the bonehead errors that kill you. Requirements that conflict with each other, are not clearly stated, don't make sense, are impossible, or are missing. Remember that your programmers will happily build anything you tell them to, whether it makes sense or not. Requirements inspection takes so little effort that deciding how to pay for it isn't even an issue.

2. Risk analysis and management. Get project stakeholders from a wide variety of levels, backgrounds, and organizational units to write down everything they can think of that might go wrong. Brainstorm it, anything goes. Only then do you figure out (or guess) how likely each risk is and how much damage it will do. This includes stuff like the champion developer being hit by a bus or pulled off the project by someone else's higher priority "emergency." Are project steps contingent on somebody somewhere else finishing something they're doing on time? This is the real world so that is a risk. Bugs in a COTS package? It happens all the time. End users saying, "Hey, that's not what I wanted even though I guess it is what I asked for"? See "requirements inspections," above. When you've identified the most horrifying risks, develop a strategy to A. avoid them, B. minimize the likelihood of their occurring, C. minimize the damage they can do, or
D. live with the consequences.

Just do THESE TWO THINGS and overnight you will become one of the most successful IT project managers in America. Get all your friends to do it and we might stop losing jobs to overseas competition.

Collapse -

Good ones

by Tony Hopkinson In reply to Some practical advice

I'd add pay far more attention to changes in scope than in function. The latter can be managed, scope creep means you went wrong on day one.
Change control, if you do nothing else in that lifetime of the project aside from the starting documentation, do keep an eye on this. I've lost count of the times, I've seem some innocuous good thing to do allowed in to the project **** the schedule out of the water.
Generally this sort of thing get's sold to a powerful stakeholder and all of a sudden it's in. The cost is first quality then other necessary but less marketable functionality. There's always going to be a phase II, so use it. An intelligent designer will simply bear it in mind so it's not made impossible/not cost effective in phase I.

Collapse -

Sounds High Risk

by Wayne M. In reply to Process and methods

From the description above, this project sounds like it is very high risk and you need much more help than you are going to get on any online site. Here are a couple of quick suggestions.

1) Find a mentor in your company who has successfully delivered a project. Don't worry about corporate standards or a big ticket item like RUP. Copy something that has worked in your company and that you can get advice about on a daily basis if needed.

2) Break into 2-3 subgroups with your most experienced developers in charge. 10 developers, especially if there are a lot of newbies, is too much to manage. You will run into time conflicts between leading your people and representing your project to the rest of the world.

3) Read up on Scope Management. Scope management needs to be put in place immediately.

4) Plan an iterative or phased development. From the description, your team does not have the expertise to deliver an important and large software project. Find a basic subset that your team can deliver in less than 3 months and schedule it for at least 6 months. Your team needs to get some experience under its belt and your team, your project, and your company will probably need to have an early success. Any large project will hit some brick walls. If you do not have some prior successes to point at, this can finish a project.

My advice is to carefully evaluate your situation to see if there is a reasonable expectation of success. Don't go overboard trying new things, your team has enough ramp up issues as it is. Find any existing expertise in your company and make use of it.

Good Luck!

Collapse -

large project, small newbie team

by BatmanG8 In reply to Process and methods

"a quite important and large software project...
it's a new development team (11 people)"

Make up your mind. Is it a large project, or are
there only 11 people on the team? (Meanwhile,
hundreds of thousands of experienced programmers
and software engineers remain un-employed and
under-employed in the USA.)

I've worked in shops where we had 200 people
working on a set of great software products
totaling in the range of 800K lines of code
(loc), and shops where we had 1 or 2 people
working on good products of 11M to 15M loc each
(no good tools to count function points).
Something in between would seem to be optimal.

In the 200-programmer team we had great software
source code repositories, change/version control,
SQA library management systems, code review, beta
testing program, etc. (better than anything I've
seen since).

I've never worked at a shop that had very good
diagramming tools (one place had some tools under
development to do detailed and massive data-base
modeling, but we'd usually use a powerful CAD/CAM
package to generate diagrams). It would
certainly be helpful. Apple has incorporated
some diagramming in XCode.

I get the distinct impression that a lot of the
"process model" and "methodology" way of
approaching everything comes from a severe case
of academia. Yes, we should use variations of the
scientific method in everything we do (see what
works, what doesn't, learn from it, then try
variations, see what works...).

Look at agile methodologies including eXtreme
Programming (XP), test driven design (TDD),
Nijssen's Information Analysis Methodology, etc.

Collapse -

by CBV In reply to Process and methods

Thank you everyone for your suggestions and comments. We will go iteratively on this, and with a core project team. We also have someone with experience that hopefully will be very active in this project.
In time I will keep posting new things here.. just in case. :-)

Thank you.

Related Discussions

Related Forums