Jag Venugopal's Blog

June 26, 2009

Critical Decision Making Audio Course

Filed under: Management — Jag @ 4:42 pm

This is a plug for an audio course titled “Art of Critical Decision Making” by Professor Michael Roberto. I’ve had the pleasure of taking his Strategy capstone class as part of my MBA at Bryant University. It was somewhat of a coup for Bryant, a well regarded small school in RI to get him from Harvard. His class was intense and interesting — never a dull or boring moment. Buy his course, you won’t be disappointed.


PMI — Project Management Advocacy? NOT!

Filed under: Project Management — Jag @ 1:47 pm

A professor of mine at Northeastern U. once remarked that as professional organizations got to a certain size, their business focus changed from advocacy of their specific profession, to paying the salaries of their employees.

While my professor was making these remarks about the ACM, I am afraid that this is turning out to be true of the Project Management Institute (PMI). PMI’s mission has turned from advocacy of project management, to perpetuating itself via sales of the PMBOK Guide, certificates, accreditation and seminars.

Back in the mid-to-late nineties, the PMI was a professional organization of project managers. They had a dedicated following (at least in my then-employer) of hard-core project managers who believed in what they did, and in the value of the PMP certification. Their main standard was the Guide to the Project Management Body of Knowledge (PMBOK Guide). This was a terse, well-written document that was available for free on the PMI web site. In addition, the PMI mailed a paper copy to each and every member as part of their membership benefits.

As the PMP exam hit the big time, so did the PMI grow in popularity. As the PMI grew in popularity, so did their zealousness to guard their crown jewel, the PMBOK Guide. Said guide was now available only to PMI members. Others could purchase it for a fee. Furthermore, the membership benefit was reduced from a paper copy to a PDF copy on CD. The PMP exam hit the big time, and a nice ecosystem built up, geared towards the PMP exam, and the training and paraphernalia needed to pass it. PMI, and the various training providers had a nice symbiotic relationship — they each needed the other to make money off the PMP.

Fast-foward to 2004. The latest edition of the PMBOK Guide was now greatly increased in girth. It was an unmitigated disaster that did not appear to have been reviewed by any well known authority in project management. I have a separate post that goes into its many sins (see http://www.amazon.com/review/RT06BMU8A0P1X/ref=cm_cr_rdp_perm). It continues to be a bestseller because the PMP is all the rage. Unfortunately IT managers who know no better, consider the PMP as a benchmark of project management proficiency. Nonsense. What the PMP certifies is that you know your way around the PMBOK Guide and can successfully answer a multiple choice test. It says nothing about your ability to manage a project under real-life conditions.

The 2008 PMBOK Guide puts on more weight, and takes knowledge hoarding one step further with multiple DRM implementations. The first was a PDF plugin that was universally disliked, forcing the PMI to revert to custom watermarking. The PMBOK CD is not DRM’ed with a similar copy control scheme. When I complained to the PMI, their response was that it was “their intellectual property” and that they needed to protect it. Its almost as if the Church one day woke up and decided to call the Bible its intellectual property.

Notwithstanding the fact that the PMI’s avowed mission was to “advance the practice, science and profession of project management”, with all the added credentials, PMI’s business now appears to be:

  • Selling certificates of various kinds (PMP, CAPM, PgMP, PMI-RMP, PMI-SP)
  • Selling accreditation to training providers
  • Selling advertisements on its web site and magazines
  • Selling books that were written by uncompensated authors (e.g. PMBOK).

For IT professionals, I recommend that PMs continue to keep their PMI membership current, and horrors, take the PMP exam. The value of the exam is questionable at best, but since PMI’s marketing has convinced the IT industry to add this to any PM job requirement as a checklist item, you’re forced to have it.

June 24, 2009

Scope Management Through The Project Lifecycle

Filed under: Project Management — Jag @ 6:16 pm

As far back as 1987, poor scope management was recognized as a principal reason why projects failed (Wawruck, 1987). Nevertheless, scope management continues to occur as a factor in project failure (e.g. see Google(1)).  Even prominent authors (e.g. see Wysocki, 2007) regard scope (or change) management as primarily a process of filling in a change management form and a project impact statement form.

 In this article, I discuss the following key components of a scope management process. I also highlight the points during the project lifecycle in which scope management comes into play.

  • Setting expectations on scope management
  • Identifying how a change in scope is detected
  • Quantifying changes in scope
  • Documenting changes in scope
  • Approving changes in scope
  • Implementing changes in scope

 Setting expectations on scope management

 Novice project teams start managing scope when they notice that the user has requested a feature which does not appear to be in the original project scope. The project manager starts quoting the requirements document to the client in the hopes of obtaining agreement that the feature being requested represents a change in scope. The client, more often than not, sees the feature request as merely an elaboration, or something that was always intended. They balk at acknowledging it as a change, much less pay for it or accept a schedule slip. Such discussions are almost never pleasant, and end in a compromise solution that can leave both the client and project team feeling that they caved in to the other party.

 The best time to set expectations on scope management is at project inception, when the project charter and statement of work are being discussed. At this point, the project team needs to reach agreement with the client on how scope will be managed. The client needs to understand that changes to scope have a cost associated with them, that will need to be managed, and that the farther one goes down the project, the greater the cost of a scope change. The project manager can have better buy-in from the client on scope management if they can demonstrate to the client that proper scope management is part of the project methodology, and can reduce their risk of not hitting schedule and cost milestones on the project.

 At project inception, the project manager has been successful in scope management if they get buy-in from the client on:

  • The desirability of a scope management plan, with the understanding that it is being put in place to help the project succeed.
  • A budget for unanticipated scope changes that will nevertheless occur as better knowledge of the system is developed.
  • Establishment of a change control board to review and approve or reject scope changes. Such a change control board would have, among others, the project sponsor, the client project manager and the consultant project manager as its members. Various client line managers that are impacted by the project may also participate in this board.
  • Agreement that project scope is determined by the signed-off project requirements.

 Requirements  Gathering Phase

 Because project scope is not yet defined during the requirements phase (other than probably high level scope boundaries), this phase is naturally open-ended. When consultancies agree to execute the requirements phase on a firm-fixed-price basis, it can lead to unnecessary tension between the client and the project team. The client is interested in fully elaborating project scope, so that changes do not have to be made in downstream phases. They are still trying to figure out exactly what they want, and are looking for discussions and consultation to help firm up their mind. The consulting organization, on the other hand, has a certain timeframe in which they need to get their requirements phase completed and the project transitioned to the next phase. 

 I worked for a high-flying consultancy in the ’90s that quoted fixed-prices for requirements phases. This had the unfortunate effect that when the time allotted for the phase was complete, the phase was declared to be over, even if the requirements were not properly elaborated. Another particularly vicious practice at this (publicly traded) consultancy was to ensure that requirements phases never crossed quarter boundaries. The phase would be terminated early if it became apparent that it would drag into the next fiscal quarter, thus not allowing for revenue to be recognized in a timely manner. Such shenanigans on requirements invariably meant poor requirements, leading to multiple scope changes during development, leading to the team falling further behind on a fixed-price development, leading to further corners being cut. In other words, a vicious cycle of scope changes that was difficult to get out of.

 Recognizing Scope Changes

During the requirements phase, it is difficult, perhaps inappropriate even to control scope. This is because scope is still being elaborated. Thus, a time and materials approach for the requirements phase allows both the client and the project team to discuss project scope fully, without any extraneous considerations getting in the way.

One way to ensure that the requirements phase is not open-ended is to divide it into two sub-phases:

  • Scoping: During the scoping sub-phase, a list of features/use cases is created, without necessarily elaborating it to a detailed level. For each such feature or use case, a determination is made on whether it needs to be implemented in the current project (phase) or in a future project (phase).
  • Requirements elaboration: The use cases or features identified in the catalog for the current project are elaborated

 Key to detecting scope changes downstream of the requirements phase is to have the business requirements signed-off, and therefore, baselined. As part of the sign-off process, the client must clearly understand the implications of their sign-off for future scope changes. Ideally this would have been discussed and completely understood at project inception itself. If the requirements are not signed-off and baselined, it is virtually impossible to argue that any change in a downstream phase is a change in scope.

 Quantifying Scope Changes

 Changes in scope have the ability to impact virtually all downstream deliverables of the project. Some examples of the impact of scope changes are:

  • Changes to the requirements document, re-baseline with signoff
  • Changes to software design
  • Changes to software already developed
  • Changes to test cases and test data
  • Changes to application help and user manuals
  • Changes to the deployment plan
  • Changes to the training plan
  • Changes to the end-user communication plan

 For each of these areas, the additional tasks and the effort hours will need to be identified. A revised what-if project plan will need to be prepared with these impacts taken into account. The project plan should reflect schedule and cost changes as a result of the scope change.

 Documenting Scope Changes

 Once all the preparatory work discussed in the prior sections has been completed, creating a scope change document is straightforward. There are many templates available, most of which are adequate to do the job. The template should contain the following fields:

  • Change request number and title
  • Business-domain description of the proposed change, and the rationale for it
  • Any potential workarounds that would obviate the change
  • Details of impact of the change on various areas (as discussed in the section titled Quantifying Scope Changes)
  • Schedule and cost impact of the change
  • Approvals
  • Supporting documents (e.g. the proposed new project plan, wireframes if available, etc)

 Approving and Implementing Scope Changes

 With all the work that has gone into both the scope change process and the scope change request itself, the process of approving and implementing the changes should be straightforward.

 Depending on immediacy and impact, scope changes can either be reviewed during the next or change control board meeting, or one can be specially convened to discuss the change. During this meeting, a decision is made to either approve the change, reject it, or send it back to the drawing board.

 Once a change has been approved, the updated documents (project plan, requirements, design, etc.) are re-baselined. The tasks pertaining to the change have now been entered in the project plan, and are treated similarly to other project tasks.

 Special Considerations

 Cost of Analyzing Changes:  For some change requests, it takes time (and therefore money) to understand the proposed change, document its impact, and then discuss it before the change control board. Analyzing such a change will have a cost and schedule impact, even if the change is ultimately rejected. The ways to deal with such changes are:

  • Discuss up-front with the client the costs of analyzing the change and obtain approval to proceed with analysis
  • Absorb the cost — especially on a large project with infrequent changes, where the probability of the change being approved is high. The cost of analyzing the change then is simply the cost of sales. Clearly this can’t be done beyond a point, but there is some value in not appearing as a nickel-and-diming consultancy.

 Small and Frequent Changes: For some changes whose impact is relatively small, the overhead of an elaborate change management process may seem to be too much. One potential way to address this would be to establish a cost/schedule “bank”, against which such changes would automatically be counted, if approved by the client project manager. Eventually when this bank is depleted, a request will be made to the change control board to replenish the bank.


Wawruck, Walter (1987). Scope Management – Important But Neglected. Retrieved June 24, 2009, from Expert Project Management by Max Wideman Web site: http://www.maxwideman.com/guests/scope/management.htm

 Google Search for Poor Scope Management(1). Retrieved June 24, 2009, from Google Web site: http://www.google.com/search?hl=en&q=poor+scope+management&aq=f&oq=&aqi=

 Wysocki, Robert K.. “Chapter 10 – Monitoring and Reporting Project Progress”. Effective Project Management: Traditional, Adaptive, Extreme, Fourth Edition. John Wiley & Sons. © 2007. Books24x7. <http://common.books24x7.com/book/id_17023/book.asp> (accessed June 24, 2009)

June 23, 2009

The Reaction If Someone Declared Indian Grads Unemployable

Filed under: India — Jag @ 2:28 pm


Recently, the Indian CEO of HCL Technologies had a severe case of “foot in the mouth” disease when he declared “most American technology grads are unemployable“. I decided to imagine what would have happened if a US Tech CEO (Freddy Flintstone, CEO of TechInc) came to, say, Mumbai, and grandly declared that most Indian grads are unemployable. Here’s my take:

The utterances of Freddy Flintstone were roundly condemned in Parliament as another example of racism — members across the political spectrum saw this as strong evidence of the western countries trying to put down the emergence of India by denigrating its achievements.

The CPI(M) commented in its newspaper that this was yet another instance of cultural imperialism unleashed by the oppresive American nation, and that the proletariat of India must stand up and loudly declare that such denigration of Indian intellectuals will not be taken lying down. The politburo of the CPI(M) further stated that India had lost all self-respect when it aligned with the US and concluded various treaties, including the Nuclear Deal. It saw this statement as the latest manifestation of US hegemony. They stated that this would never have happened if India had instead aligned itself with China.

Mulayam Singh Yadav of the Samajwadi Party declared that every Indian grad would have been employable if only India did not have computers, and was not subservient to the English language.  He stated “There would be so much work to do by hand in all offices that not only would all Indian grads have been employed, we would have had to import graduates from Bangladeshi universities to meet the demand”.

The Sangh Parivar stated that India ought not to depend upon western teconology and computers, and instead, needed to design and develop its own computing systems based on ancient vedic principles, using Sanskrit as the programming language. The BJP has decided to organize a boycott of Intel, AMD and Microsoft as a means of retaliation. Further, the party stated that its IT manifesto would include deployment of Linux on the Nokia 810 tablet in all central government offices.

Members of the Akhil Bharatiya Vidyarthi Parishad called a week-long strike of all colleges in the country as a sign of protest. For good measure, they burned effigies of Freddy Flintstone, Steve Ballmer, Bill Gates and Larry Ellison all across college campuses in Mumbai. (For the record, some students complained that the strikes were organized to postpone semester-ending examinations, which were scheduled to have started this week; however they refused to go on camera).

The Shiv Sena issued a notice to TechInc to shut down all facilities in Mumbai. Shiv Sainiks led by FlavorOfTheDay Thackeray went to the TechInc office in Mumbai, destroyed their data center, and caused grave bodily harm to a visiting employee from a foreign office (he has been admitted to Jaslok Hospital, where he is said to be out of danger). In addition, they burned a number of Ford, Chevrolet and Opel cars to signify their disapproval of the American companies that made them (it is reported that all the owners of these cars were Indian, but that’s a small matter).

The Prime Minister issued an appeal for calm, and to not let such utterances disrupt Indian society. The American ambassador was called in to the External Affairs Ministry and told in no uncertain terms that Indian grads were very much employable. The Ambassador, in return, mumbled something about Freddy Flintstone being misquoted, and how highly his nation thought of Indian students’ employment prospects upon graduation.

Narasimha Reddy, an “agent” in the Ameerpet area of Hyderabad had the final word — “All this talk of Indian grads being unemployable is nonsense. I can provide you a degree certificate from the IITs, which will assure you an instant job offer and an H1B from the US consulate in Chennai. Money back guarantee, only Rs. 10,000”.

June 22, 2009

Agile Software Development: Avoiding Sucker’s Choices

Filed under: Information Technology,Project Management — Jag @ 7:41 pm

“Agile” seems to be one of the more misused terms in software engineering these days. The Manifesto for Agile Software Development defines agile as any process that emphasizes:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

 These points are like mom and apple pie. There can be no arguing the ideals that they represent. No one in their right mind would consider processes and procedures more important than individuals on a team. Neither would any sane person pat themselves on the back for well-written documentation if the software did not work. Only the absolutely lunatic (or staff at software monopolies) would consider customer collaboration irrelevant. Similarly, any project manager worth his salt ought to be able to respond to change in a manner that meets business needs.

 However, in many situations, the meaning and intent of “agile” has been perverted to an ad-hoc, laissez faire approach to project implementation that pays little heed to either managing to a plan (schedule, cost) or any predictable software development process. In my personal experience with various allegedly agile methodologies, and their equally dubious practitioners, the ideal is great – it sells a lot of books and conference seats, but falls short in providing working systems. What follows is my take on how the agile manifesto is morphed into software engineering absurdity, and what to do about it.

Properly Documented Requirements

 I know of one “agile” project manager that believes business analysis is a profession doomed to extinction. His preferred method of requirements capture is an object model (in Visio), supplemented by meeting minutes. The jury’s still out on his project, but all of my experience points in a different direction — well-written and to-the-point requirements.

 Sure, writing requirements takes time. But more often than not, it not the writing that takes time (team members with good skills can whip out large documents in half a week); what does take time is the process that happens before the writing. Such things as user workshops, focus groups, interviews, issue follow-ons, hunting for redundant or contradictory requirements, etc.

 A second pet peeve of mine, which is more magnified in an agile environment is requirements being slapped together to meet arbitrary deadlines, without much thought to how well-written and internally consistent they are. A project that I was peripherally involved in produced such voluminous requirements (mostly because they didn’t bother to write it well) that it was all discarded as being un-reviewable, un-maintainable, and impossible to code from.

 When someone insists that they prefer working code to elaborately-written documentation, they’re giving you a sucker’s choice. No one insists on thick binders of documents; instead, what I am talking about is requirements documented by competent business analysts, using the fewest words possible, and yet conveying the intent. This document can and must be reviewed and signed off by the customer. It educates the rest of the team, including QA specialists, technical writers, and project managers.

 To WBS Or Not To WBS

Any team, whether agile or not, needs to be able to provide a clear work breakdown structure — a high-level WBS for the entire project, and a detailed WBS for the current iteration. The WBS must contain a hierarchical structure of tasks, with proper dependency relationships between them.

 The presence of a properly thought-out WBS provides a level of assurance that the project team knows what it is doing; what tasks are needed to achieve a goal, and what the ordering of goals is. A hierarchical structuring to the WBS allows for tracking the completion of intermediate items during the iteration. Being able to demonstrate these intermediate items allows the team to prove that it is on track. Well-thought out predecessor and successor relationships ensure that the team is working on those tasks which can be driven to completion (ones for which all predecessor tasks have completed). This helps prevent the 90% completion syndrome where each task quickly reaches a reported 90% level of completion and stays there for the entire iteration (and often beyond), because upstream tasks are still incomplete.

 Arguments are made by agile proponents that such WBS creation and dependency identification is a waste of time. My response is that a well-prepared team ought to know what it needs to do, or the preparation is insufficient for a short-duration iteration. If the team is not able to provide a well thought-out WBS with clear explanations of each work item, then it would make sense to spend an initial 5-10% of the iteration duration in figuring out such a WBS.

 Estimates for Individual Tasks

Once a WBS has been created for an iteration, the team ought to be able to estimate each individual task. Estimates are never perfect, but an imperfect estimate, made in good faith, is much preferable to none at all. Estimates allow for the project team to confirm that their WBS is achievable within the desired completion dates of the iteration. When resources are named to each task, the estimates also provide a good idea of resource loading. This helps prevent situations where resources are overbooked on multiple simultaneous tasks, or are underutilized. As estimates and actuals are collected, they can be reviewed by the team to identify over- or under-estimation, and to appropriately recalibrate.

 Digression: Three Point Estimates Aren’t

There is literature suggesting that a three-point estimate can be better than a single-point estimate. In a three-point estimate, a developer provides an optimistic, most-likely and pessimistic estimate for each task. These are averaged out using a formula with some weightings to come up with a single point estimate. The argument goes that this approach forces a developer to think through all possibilities rather than the most optimistic scenario alone.

 The theory sounds good, and the aims are noble. However I have not seen this being effective, in practice. When a developer has fixated on a number as an estimate, I have found that they generate the other two points using math, rather than thinking through all scenarios. For example, a developer may decide that coding a module takes 4 days, and wants the average to show up as such. Rather than give much thought to the optimistic and pessimistic scenarios, the developer merely finds two numbers equidistant from their estimate (say, 2 days and 6 days), so that the average turns out to be their preferred number.

 The project manager is sometimes faced with an argument from “agilists” that the iteration deadline is known, and the WBS is known, so could the PM please back off and let the team do its work. There is a grain of truth to their complaining — estimating takes thinking and work. However, it is an investment worth making, if only to confirm that the iteration can be successful. Absent proper estimates, the project manager is flying blind, relying only on assurances that the iteration goals can be achieved in the promised timeframes. This may work if the iterations are very small (say <= 2 weeks). In such small iterations, it immediately becomes clear if the team is having trouble meeting its goals in a timely manner, thus allowing for remedial action to be taken. However, the longer the iteration period, the greater the risk that the team may experience an unpleasant surprise. An iteration of one month’s duration that takes a month and a half has just lost 15 days on the overall project. With proper estimation, this might have been avoidable.

 Project Tracking

Tracking the status of tasks on a weekly basis can be a lightweight effort for individual developers, yet can provide assurance that the project is on track. In my projects, I ask developers for just two key pieces of information for any task that they have worked on during the week:

  • Number of hours worked on the task
  • Number of hours remaining on the task

 For a well-prepared developer who knows what they are doing, both numbers should be easily trackable in under 15 minutes per week. This allows the project manager to determine actual task completion percentages, and roll it all the way up the WBS. This method of calculating task percentage complete is far better than asking the developer directly for a task’s completion percentage, the numbers are concrete and meaningful, rather than having to guess a completion percentage. If, week after week, the remaining hours on the task are steady, then a conclusion can be drawn that the estimates were poor, or that the developer is having trouble completing the task. This allows for remedial action to be initiated.

 In case of outsourced resources, rigorous project managers correlate hours worked reported each week to contracting invoices. If a developer bills for 40 hours, then it is easy to determine if they have demonstrated 40 hours of progress on the project, using this tracking method. This allows for better cost and vendor management, than just completion percentages. It may seem excessive to apply the same tracking to one’s own employees’ hours, but I’ve seen it done in consultancies that live and die by the billable hour.

 An easier approach to project tracking is to break up each task into no more than 20 hours’ effort. When a task is started, the project manager marks it as 50% complete. When it is completed, then and then only, is it marked 100% complete. There are no other levels of completion. Using this approach, each task can be completed in one, or at most, two reporting periods.

 Project tracking using one of the above two approaches will allow the project manager, whether the project is traditional or agile, to accurately track and report on project progress. Of greater importance, it surfaces problems early and provides an opportunity to address the underlying issues. Such tracking is initially met with resistance in settings where the team is not accustomed to it. This resistance is usually dissolved by promising the team that the tracked hours will only be used to update the project plan, and will not affect such areas as pay and promotion (obviously, the PM will need to abide by their promise). Another approach to dissolving resistance is to seek the buy-in and advocacy of the line managers, to whom the project resources report.

 Responding To Change Over Following A Plan

Inherent in the title is yet another sucker’s choice. It is indeed possible, even imperative that a competent project manager follow a plan, yet be flexible enough to respond to change, when the circumstances demand it. To make this an either/or choice is to trap the unsuspecting project manager into having no scope control. The right word to have used instead of “over” in the section title is the word “and”.

 Responding in a deliberate way to change is easier when there is a change management plan (with due apologies to the agilists). Any change management plan should address:

  • Detection of the change — how do we know that a change has occurred? How can we prove that it is a change?
  • Analyzing the business impact of the change
  • Analyzing the overall project impact of the change
  • Getting the change approved/rejected
  • Planning for the change
  • Implementing the change

 I’ll talk about a change management process in another post — the only point I want to make here is that responding to change does not need to be difficult. When requirements are written well, and they have been signed off, it is relatively simple to detect and discuss changes — in a planned way.


The agile manifesto, and indeed the proponents of various agile and extreme methodologies present many sucker’s choices. In this post, I’ve tried to debunk some of them. The responsibility of the project manager when faced with a sucker’s choice is to replace the word “or” in the question with “and”, and then go about finding a solution. While elements of the agile movement have their merit, one must acknowledge that other practices and beliefs run contrary to common sense. It is up to the project manager to pick the good, discard the bad, and move on.

June 12, 2009

Visa consultants, and the pursuit of the American Dream

Filed under: India — Jag @ 3:49 pm

It is but natural to want to improve one’s educational or economic standing. Thus, there are large numbers of Indians who wish to emigrate to a western country to either pursue higher degrees, or a well-paying job, or both. The desire is so great that a number of visa consultancy shops have sprung up which cater to this demand. See, for example:



 The modus operandi of these consultancies appears to be to:

  • Fill in various forms required by the consulates for the grant of a visa. Generally check up on paperwork
  • Conduct mock interviews
  • Update the prospective visa seeker with the latest consulate rumors (e.g. “The tall white male guy with a beard is rejecting a number of applications. Here’s how to deal with him if he interviews you…; the woman is more sympathetic, and here’s the strategy to follow when interviewing with her…”)

 There is nothing inherently wrong or illegal about these services, though one may question the need for them (clearly, if you want to immigrate to a foreign country, you ought to be competent enough to fill in a 2-page form on your own). Furthermore, coached interviews often get the applicant into trouble because the answers are likely to be manufactured. The applicant will most probably have difficulty keeping their “facts” straight under persistent questioning. My advice to prospective students and work-visa seekers is to fill in forms by themselves, and above all, to be scrupulously honest in the statements they make, lest they be disbarred permanently from entering their chosen country.

 There are some places, however, where these consultants start deviating from providing assistance, into peddling dubious university courses and false hopes.

 Both the above consultants offer what is known as a “Work-Study Program” for prospective students in the USA. Aspirants are promised that they will be able to work immediately in the US, with US employers, without restriction. All that they have to do is to sign up for a couple university courses at night. In their web site content and promotional brochures, the emphasis is always on the “work” portion of the “work-study” program, with “study” being an afterthought, mainly as a way to get the visa.

 Large numbers of Indians, especially from the smaller cities, appear to fall prey to such enticements. A look at the testimonial section of “Opulentus Overseas” shows a number of starry-eyed youngsters absolutely ecstatic about their work-study program visas. When I look at them, I understand what they’re trying to do, and am sympathetic to their dreams — after all it was not that long ago that I was in the same state.

 The reality, as always, is both harsh and different. For one thing, these “work-study programs” are available at third-tier universities in the US (names like Coleman University, Keiser University, Lincoln University, etc). The quality of the education available at these universities is likely to be very suspect. There is not one ivy-league university on their list. Not even a decent non-ivy university, like, say, BU or Northeastern.

 Secondly, all these “work-study” programs are administered by one company, HTIR (http://www.htir.com) which appears to be an out-and-out commercial enterprise, that offers legal cover to obtain work authorization, under the guise of a co-op program. Significant amounts of fees are payable to HTIR (see, for example, http://www.htir.com/images/forms/Explanation%20of%20Costs%20Keiser%204%2009.pdf), including a “cultural assimilation package”for $2975, and “Employment assistance package” for $950. This package is sold as assistance in obtaining an SSN, “personal advocacy” with university officials to obtain a work permit, and booking interviews with potential employers. This is absolute nonsense. Any legitimate university ought to provide most of these services _free_ through their International Student and Co-op offices. When I was a newly-arrived student at Northeastern, I paid exactly $zero to obtain an SSN, $zero to obtain work authorization, and again $zero to obtain assistance from their co-op office.

 Thirdly, the “work” that these programs obtain for their “students” is promised to be prestigious jobs at American corporations. The reality is that the majority are placed in minimum-wage jobs that are totally unrelated to the degree they are allegedly pursuing. For example, browsing http://www.opulentusoverseas.com/html/will-i-get-a-job1.htm shows the vast majority earning in the neighborhood of $10/hour as chefs, “sales representatives” etc. at the neighborhood resturant or Dunkin Donuts franchise. At this pay rate, assuming 25% tax (net pay of $7.50), it would take approximately 525 hours of work (a quarter-year) to pay back HTIR’s costs, never mind tuition, and living and board.

 The unkindest cut to these prospective students is that once they have completed their degree, their prospects for well-paying employment are remote at best. With the US in a recession, and with H1B visas limited to 65,000 it is quite likely that many will not find the job of their dreams, after having paid significant amounts. In pursuit of the American dream (and to avoid the stigma in Indian society of “one who went but couldn’t cut it”), many will likely be forced into undocumented labor (e.g. at the nearby Indian grocery or restaurant), or low-paying jobs at Indian-owned consultancies. With the current wait for a green card at approximately one decade, they will likely be stuck in immigration limbo for most of their next 10 years.

 My suggestions for prospective students or workers heading to the USA are simple and straightforward:

  • If you’re a student, have realistic expectations on what you can earn and what you cannot. Be honest with yourself on how much money you can afford to spend.
  • If education is important to you, seek it at a reputed university. Understand that you may end up spending about $30-40K for your degree, which you may or may not recoup.
  • Its dreadfully tough to get a job in this economy. Even worse if you’re looking for an H1B visa and have only a dubious “degree” to show. You’re most likely to end up being employed by an Indian “consultancy” at bottom-market rates, working long hours and sharing a house with many, many people, and with immigration paperwork of questionable legality.
  • Absent any immigration reform, the chances of your landing a green card anytime soon are exactly zero. Which means that you will be at someone’s mercy for your work authorization, all the time. And, the political climate right now for any immigration reform is just not there.
  • Ask yourself — is it worth it? You and only you can answer this.

June 3, 2009

The Relationship Between Project Management Processes And Software Development Lifecycle Phases

Filed under: Project Management — Jag @ 6:40 pm
Version 1.0, 01-June-2009

 Authors of project management textbooks, and their readers sometimes confuse project management process groups with the phases of a software development lifecycle. This note attempts to clarify the relationship between these two concepts.

Project Management Process Groups

The Guide to the Project Management Body of Knowledge (PMBOK) describes five project management process groups. They are:

  • Initiating
  • Planning
  • Monitoring and Controlling
  • Executing
  • Closing

 According to PMBOK, the project management processes “… ensure the effective flow of the project through its existence“. This is contrasted with product-oriented processes, which “specify and create the project’s product“. PMBOK attempts to distinguish between the two – while the former is said to apply globally and across industry groups, the latter are said to vary by application area.

Project Phases

Project phases are a grouping of product-oriented processes, and are heavily dependent on the product lifecycle and application area. For example, a generic “waterfall” software development methodology might include the following project phases:

  • Scope
  • Design
  • Development
  • Testing
  • Deployment

 Trouble arises when users conflate the two and imply that:

  • Initiation = Scoping
  • Planning = Design
  • Executing = Development
  • Monitoring and Controlling = Project Management and Quality Assurance
  • Closing = Deployment

 At least one author has gone down this erroneous path. What is particularly embarrassing is that the author is well published and well known.

Processes at Macro and Micro Levels

Click here for a larger copy of the picture below.


  The correct way to think about the relationship is that the project management processes are performed at the macro level – across the entire software project, and at the micro-level, during each phase. Some examples are provided below, for an iteratively executed project of multiple phases, with incremental delivery of desired functionality in each phase:

 Initiating: The “Develop Project Charter” process occurs once for the entire project, at the beginning of the project. Similarly, the “Identify Stakeholders” process is performed once for the entire project. However, during each phase (scope, design, …) the project charter and the business case are reviewed for applicability in light of information that might have been uncovered in the preceding phase. Furthermore, if one were to take a broader view, the initiating process at each phase would involve making a go/no-go decision based on the results of the previous phase.

 Planning: At the macro level, the planning processes answer the following questions:

  • What should our solution be? What are its components? What functional and non-functional requirements do our users expect from the system?
  • What is our prioritized list of features?
  • How many phases do we think we need?
  • How many production deployments do we need?
  • What will our resource loading look like?
  • At a high level, how much will all of this cost? Does it justify the expected return?
  • What is our QA strategy? What parts of it will we automate?
  • What is our architecture?
  • How will we communicate progress?
  • Do we need a steering committee? Who needs to be on it?
  • What are our risks? How will we handle them?

 Clearly, many of the answers will not be definitive, but will serve as best guesses for what the iterations will bring. Phase-level planning is very different – and is concerned with the deliverables due from that particular iteration. Such planning would involve clarification of requirements, creation of teams and subteams for the iteration, refining the feature list for the iteration, test cases to be written, etc. A detailed project plan with resource leveled dependencies would be created for the iteration.

 Executing: Some of the project level considerations for the executing process group are:

  • Staffing the entire project with members that will outlast individual iterations
  • Managing stakeholder expectations for overall delivery and cost
  • Identification and on-boarding of subcontractors such as staffing agencies
  • Change management (e.g. reviewing all change requests at the steering committee level)
  • Technical writing (e.g. user manual, online help, etc) and training.

These topics might be refined in each phase, but they need to be discussed beforehand. Phase or iteration level execution is concerned with creating work packages for the tasks in the plan, and assigning them to the development staff, generating status information on tasks, assessing and dealing with risk, and employee management on a day-to-day basis.

 Monitoring and Controlling: At the phase level, it is concerned with successful completion of the phase — in many iterative methodologies, a hard line can be taken against scope changes that occur within an already-executing phase. Other tasks during each phase include status reporting, quality assurance testing, and procurement (e.g. of hardware and software).

 The monitoring and controlling processes at the overall project level are concerned with the progress of the project as a whole, and whether project execution is proceeding along the lines of the plan. Considerations at the project level include the overall project progress and whether the breakdown of functionality into phases needs to be revisited. Questions that arise are whether two or more phases should be combined, or whether phases need to be added to accommodate change requests. These change request may not impact the currently executing phase, but might require the addition of an entirely new phase to accommodate it.

 Closing: Phase closeout is concerned with the completion of phase deliverables and transition to the next phase. Project closeout is concerned with such things as deployment, contract or staff termination, final documentation, contract closure and signoffs, etc.


Project management processes are executed at the project and phase levels, and must not be confused with the components of a software development lifecycle. Both are essential to a successful, deliberately executed project.

June 2, 2009

Improving project status meetings

Filed under: Project Management — Jag @ 7:42 pm

One of the rituals of project management is the weekly status meeting. When managed poorly, this can be a significant waste of time for all members on the team. This occurs, for example, when every single attendee, in round-robin format, states what they did during the past week, and what they expect to do during the next week. This is a waste of time, because each team member could have read project status sitting at their desks, at a time that was more convenient for them.

A better approach would be to have a deadline for project status reports to be sent to the team lead or the project manager. The PM would then review each person’s status and plans, and prepare a summary status report. This summary status report would be sent to all team members well in advance of the status meeting. It is assumed in the status meeting that all team members have read the status report and are prepared to discuss their specific areas further.

The status meeting is then focused on areas of exception — where performance has diverged from plan, or where the team has run into issues. Furthermore, issues are not discussed threadbare during the status meeting. Rather, the status meeting acts only to delegate each issue to a subset of team members, who are assigned the responsibility to review the issue, come up with solutions, and report back to the larger team. As the task is being delegated, a leader responsible for the closure of the issue is identified. Other team members with a stake in the issue can ask to be included in the conversation. The task leader is given a deadline by when they need to get back to the group with a response.

Following a disciplined approach to status meetings will ensure that they are short and focused. It gets team members back to their desks sooner — which they will appreciate!

Blog at WordPress.com.