COBOL Application Project Mgt Scoping Questions

I've recently stepped into a project management position associated with the ongoing upgrades to an old COBOL financial system used for payroll.  I'm finding it difficult to nail down schedules and resource requirements for mods/enhancements I use to consider fairly simple in a non-COBOL environment.  For example, I have only two priority #1 requirements on the table at the moment but my team members can't seem to nail down a schedule or resource plan.  But, the requirements are only: 1) replace a current mailing address embedded within the systems outgoing payment leave and earning statement and the addition of a tracking number for each outgoing piece of mail.  Can anyone help provide a little more detail as to why something like this would not be fairly cut-and-dry and a short effort of only a few weeks?

Answer Wiki

Thanks. We'll let you know when a new response is added.

I can’t imagine there being any difference in your scenario just because of COBOL vs NON-COBOL. (what is your former area that is “NON-COBOL”?)

If NON-COBOL is system software or Assembler, then maybe you are dealing with a different level of knowledge (read that as “lesser knowledge”) in your new position.

Sometimes , programmers who maintain these old systems are themselves quite young and do not have the background knowledge on how these old systems work; hence they are reluctant to even touch them. I have seen this many, many times.

One more thing I must point out … are the people you are now in charge of mad or angry about you taking this position?

My point is that it has to be something other than COBOL. COBOL is just a language. Nothing more than syntax. Application system design doesn’t change. Accessing data doesn’t change. Hardware doesn’t change. So it must be something.

Discuss This Question: 3  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • Jzjohnson63
    I started my career in IT about 20 years ago and it started with COBOL and Pascal (and a little fortran). But, after some initial projects move on to integration work, computer security and then financial controls and monitoring software. My efforts began to focus more on the data and/or building web-based applications in C++, Java, etc. When reviewing the requirements on the table, all of the requirements seem pretty simple and qualify mainly as minor mods or enhancements as the applications themselves are already mature. For the most part, I'm able to take the team through the requirement, discuss the general approach and/or verbs, etc. Before me, they had a manager that had little or no technical background and I believe they've used that to their advantage to increase the team size and increase the cost. No matter how I sketch it up on the white board and no matter how many of my close friends from the COBOL consulting world I refer to I can't see how a one week task can be stretched into 5-6 months and 20+ FTEs.
    15 pointsBadges:
  • Meandyou
    Agreed. It sounds like they are lazy or too dumb to do their job or .... COBOL is still COBOL ... processing is still processing ... time to kick butt? ... time to buy them presents? ... I can't help you there because i am the worst at getting people to do things (in my case it happens to be they are both lazy and less-than-bright). Good luck
    5,220 pointsBadges:
  • JohnsonFisher
    COBOL is not brain surgery, but there is well written code, operating against well designed, normalized data, that can make for a significant delta in time estimate. That being said, as with any project, a time certain for feasibility and evaluation should yield a time certain estimate for execution of the test plan, the changes, QA with sign-off, and implementation. I can understand that a few days of research could return a variable response for project completion, within reason and, for what you describe, that should be a few days or a few weeks at maximum. What could throw this orderly view into the seeming conundrum you describe would be some workpalce and technology variables. The largest variables, for a project like this, affecting project completion time estimates include the following:
    1. IIs the software source library(s) current and complete?
    2. Are the compilers dependible and licensed?
    3. Does your QA process include COBOL program maintenance?
    4. Does your organization respect or degrade, as being obsolete dinosaurs, developers who know COBOL?
    5. As noted above, do you have developers and developer managers who know COBOL and the applications being considered for modification?
    If any items in the above list are unknown, uncertain or negative, then perhaps your developers are not lazy but honest. Walk into our shop with seveal hundred servers, dozens of web servers, app servers, database servers, security, fixed maintnenace windows, change freeze periods and any estimate you would give would be meaningless or career limiting, if you don't know the application structure or have a mentor that knows this information and is willing to share. Consider also that perhaps the developers/programmers may be distrustful of their systems or their management. Please don't take that personally, since the responses you are receiving may likely have been influenced by your predecessors.
40 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: