US Consulate warns visa aspirants

Its open knowledge that the H1B visa offers significant opportunities for fraud. Now the US Consulate in Chennai has finally taken notice, with its warning to visa seekers.

Visa fraud is so rampant, that anyone either Stateside in the USCIS or in the consulates can pick out fraud cases all day without stirring from their desks. Some examples that I’ve come across:

• The 80/20 or 90/10 scam: “Consulting” companies in the US will offer to do  your H1B and Green Card paperwork for you, run payroll, and generally give you legal cover in exchange for 10-20% of your billing rate. What makes this scam illegal is that there is no real job. The consultant creates a fake job to get you in. Then, you find your own consulting gig on Dice.com or similar sites, and have your “consultant” do the billing. If you’re on the bench and you need to show income, then just hand your “consultant” a bunch of money that he will then run through the payroll system and hand back to you.
• Fake experience: You can find any number of screen printers in Chennai and Bangalore who are expert at creating fake experience letters on absolutely-perfect looking letterheads. And if someone does attempt to verify, just give them a friend or cousin’s phone number. When they call, your relative can verify your fake credentials easily.
• Bank statements: There is a requirement when obtaining an F-1 visa to show a sufficient amount of money to support yourself in the US. This is easily taken care of by a very short term loan from the neighborhood shylock.

Ultimately what’s shocking is not the fact that the US Consulate thought it fit to write a rather stern open letter. What is shocking is that so few cases are prosecuted, either at the USCIS or the Consulate level. All that an interested USCIS enforcement officer has to do is to browse over to sulekha.com, look at the classifieds all day, and start shutting these operations down one at a time. At consulates, an easy way to detect fraud — check to see if the degree matches the job. Someone with a Bachelor of Arts or Commerce or Bachelor of Science in Zoology asking for an H1B for an IT job should set alarm bells ringing fairly easily.

On choosing an eBook reader

Barnes and Noble has released its “Nook” ebook reader.  Sony recently released a couple readers. There are rumors of others waiting in the wings.

 The blogosphere is all abuzz comparing the relative technical specifications of each one of these readers, recommending the one or the other. But I think that technical specifications of the hardware ought to be only part of the consideration when purchasing an electronic device, especially one that is a closed system such as an eBook reader.

 The first consideration in the purchase ought to be the longevity of the service. Generally, you can only buy the “software” (i.e. books) from the company that sold you the hardware.  This is important for two reasons… one, you want newer titles to be available for your device in the years to come. Secondly, you want the device to be supported for a long time, so you can read the books you have purchased, which are useless outside of the device.

 The question to ask yourself is… if I invest money in buying from Barnes and Noble or Sony, will their service be around for the next few years, or  are they likely to leave the market? Those who purchased music from Sony’s online store a few years ago must now be regretting their decision, given that the store has shut down, and the DRM’ed tracks are useful only if copied to a CD and ripped back. Similarly, B&N’s financial woes do not exactly inspire confidence. Of all the major players, I think Amazon’s the most likely to stick to the Kindle or its successors.

 The second consideration is the variety of software, and its price. Sony strikes out here, because it is primarily an electronics vendor, with little experience in book retailing. It is not at all clear that selling eBooks will be Sony’s core business. Thus, it is likely that new titles which are outside the pulp-fiction mainstream may not ever make it to the device. The struggles being faced by Barnes and Noble also raise questions about their willingness to invest in selling books outside mainstream bestsellers. They are an also-ran in the Internet book retailing business, and their brick-and-mortar bookstores are under assault from Amazon. Even on this count, Amazon is most likely to succeed, because books are core to their retailing business.

 A third, and final consideration, is what value is sought to be derived from an eBook reader. Certainly, the readers are more portable, and occupy far less shelf space than the thousand or so books each can carry at a given time. However paper, too, has significant advantages — the primary one being that it is far more resilient to falls or liquid damage. The replacement cost of a paper book is minuscule by comparison. And, it can be read, then given away or resold. It is for this reason that I haven’t yet taken the plunge into the eBook world, preferring instead to read a few limited computer titles directly on my laptop. I’m holding out for price drops on the large Kindle though… when I can read my collection of non-DRM’ed PDF books natively without re-flowing the text, then an eBook reader will make sense to me.

Desi vs. Desi

Note to my American readers: Desi is a colloquial term used by people of Indian origin to refer to each other. Somewhat similar to the word paisan.

You know your community has finally reached the mainstream when it has its own crooks. Not dealing in penny-ante robbery, but doing it Venti-size. And a US Attorney prosecuting them, who also happens to be of Indian origin.

Such is the case with Indians as of a couple days ago. The scandal involving Raj Rajaratnam (nominally a Sri Lankan, but an ethnic Tamil-speaking Indian) also ensnared a whole host of Indian characters ranging from a VP in Intel (Rajiv Goel) to a senior partner at McKinsey (Anil Kumar) and a Moody’s analyst (Deep Shah). The US Attorney prosecuting them is Preet Bharara.

Now the quiet-wage-earning-professional-Indian stereotype can be safely laid to rest.

PS: Recommendation to US Attorney Bharara… send these guys to Tihar jail in Delhi (general ward). That will be far greater punishment than any American judge can ever impose on them.

Dragging paper into the digital age

True to my reputation as Inspector Gadget, I recently bought a Pulse Smartpen from Livescribe.

The Pulse Smartpen is a little contraption that writes on special paper and does two things ordinary pens can’t… it captures handwriting digitally, and optionally, captures an audio recording that is synchronized with the writing. It is a brilliant idea that will appeal to a whole class of users in business and education, provided that some issues are addressed.

The first issue I can perceive is the legality of recording a conversation and people’s comfort with their voices being recorded. This being a state subject, different states have different laws regarding this. The state where I work (Rhode Island) appears to allow it, provided that people have no reasonable expectation of privacy when the recording is being made (e.g. in a business meeting). The state where I live (Massachusetts) forbids this, unless all parties agree to the recording being made. Additionally, people are sensitive about their words being recorded, and may not give their approval for such recording.

If both these objections are overcome, (say by far thinking managers, who make it OK to use the smartpen in meetings for their department), the pen is an excellent business tool that kicks corporate notetaking and minuteing a few notches higher.

A second issue is that the smartpen can only work with specially printed paper. The software uses a minute grid of dots to help it discern the position of the pen on the page. Livescribe sells notebooks with this special dot pattern (“dot-paper“) for a reasonable price (good paper quality, not that much more expensive than generic notebooks). Livescribe also provides a way for users to print letter-sized smartpaper by themselves. This requires a 600-DPI color printer capable of interpreting PostScript. One can print to PCL-only printers, such as the HP range commonly found in offices, with some kludging. In general, there should be no need to do this, because Livescribe’s notebooks are inexpensive and convenient (and for those who have Amazon Prime, shipping is fast and at no extra cost).

By far the biggest impediment I foresee to the success of the smartpen is the complicated technology licensing that goes with the dot-paper. This is licensed from a company called Anoto, based in Sweden, that also has a US office in the Boston area. Anoto has licensed this technology to other companies as well. Most of these licensees are system integrators that provide turnkey forms solution to businesses, along with the pen. Anoto makes money off the royalties from the technology, as well as a cut per sheet of dot-paper.

Some of Anoto’s other partners (e.g. Talario) sell a solution that could be the killer application for Livescribe’s Pulse. This solution provides the ability to print any office document with a dot-paper pattern behind it, effectively enabling the document to be used with the smartpen. An example would be to print a Microsoft Word document or an Excel document, take it to a meeting, annotate it in the meeting, and upload the document with its annotations back to the PC for recordkeeping and emailing. Unfortunately, I do not see this particular application showing up on the Pulse anytime soon… for one Anoto would not want to kill off its other partners’ businesses. For another, Anoto charges the Talario end-user a royalty of 10 cents per page for the dot pattern. I believe that this is excessively expensive, and would significantly hinder the market acceptance of the tool. A student could conceivably print her professor’s lecture notes on dot paper, and then directly annotate them if she could do so free of royalties. At 10 cents per page, it would not be cost effective. It’s similar to Microsoft selling you Windows, and then charging you a fee per mouse-click.

If Anoto were to allow royalty-free printing, and if instead it derived royalties solely from each pen sold, I think in time that it could significantly expand the smartpen market into the business and education markets (all the way from school through university). In the aggregate, it would make a lot of money from the initial pen sale, and subsequent replacement sales to a vastly expanded market.  As an aside, I would be interested in seeing if a smart software developer figures a way of printing a bootleg pattern without using Anoto’s software. That would probably infringe on Anoto’s patents. But, as RSA Corporation’s experience with early bootleg PGP versions would indicate, it is impractical to sue every single end-user.

Nevertheless, students or professionals who like to take notes on paper would be well served by the inexpensive device. Head on over to Livescribe and order your own. Before you do that, look around the Internet for coupon codes (I found one for 25% off in September 2009).

Nasscom and the US “Service Visa” proposal

It is stupefying how a supposedly expert body such as Nasscom could come up with a proposal for a “service visa”, as described in this article. Any PR company worth its retainer could have advised them that their proposal was both ill-timed and delivered to the wrong forum.

To ordinary Americans, it probably smacks of arrogance. The message says “we’re here to take your jobs, and we’re giving you advice on what you can do to make this process easier”. To Congress, it says “never mind that we’re a foreign entity, here are some suggestions on how you ought to tackle immigration reform”.

Outsourcing is a huge concern in the US today, especially with the record levels of unemployment seen in the last year. Now would be a really bad time to publicly announce cockamamie visa suggestions to a foreign government. If Nasscom had any sense, it would:

• Publicly commit its members to hiring more stateside employees, to build goodwill (or to erase at least some of the ill-will).
• Make a highly visible gesture to demonstrate that outsourcing can coexist with a good job market in the US. One example would be making a noticeable endowment to a US University for an MIS professor.
• If it does want to influence visa rules, by all means it has the right, but to do so through targeted lobbying and not through grand public pronouncements.

I’m afraid that Nasscom’s ill timed lecture to Congress will only make matters worse for any meaningful increase in H1B visas.

Critical Decision Making Audio Course

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!

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.

Scope Management Through The Project Lifecycle

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.

References

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. Books24×7. <http://common.books24×7.com/book/id_17023/book.asp> (accessed June 24, 2009)

The Reaction If Someone Declared Indian Grads Unemployable

 

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″.

Agile Software Development: Avoiding Sucker’s Choices

“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.

 Summary

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.