5 Must-dos for Recovering Failed Projects - by Shoaib Ahmed

Can't resist re-posting this recent blog post from another Project Manager (with some edits by me), as it more or less reflects my own thoughts on the subject. I have given his name in the title and the link to the original blog post at the bottom of the page. I hope these would be enough by way of acknowledgement

How can one rescue a failed project? What are some of the things that need to happen before you can achieve any improvement?

Acknowledge the failings

When doctors treat patients with substance abuse, the first thing they try to instill in the patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit that problems exist, there is no hope for a resolution. If you keep doing the same things, there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may even have voiced it. Seek those out to understand what went wrong.

Divorce emotional investments

One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of a project. The current status is a reflection of many decisions taken through the course of the project. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening

Aim for small wins

In a major failure it may sound counter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher is the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements and communicate honestly.

Throwing more resources is not always the answer

As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several fold. One of the major reasons projects fail is because communication is poor. Having large teams working on the recovery attempt is therefore more risky than the original project. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins, go for smaller teams.

Be prepared to abandon the project

For all the best will in the world, sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after  because of the additional cost. You may find that there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful not to be seduced by that. A fully functional  replacement system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.

Link:

http://network.projectmanagers.net/profiles/blogs/5-must-dos-for-recovering-failed-projects

RSS (not the saffron variety)

For much of this week, I've been helping one of my technical teams in publishing dynamic content using a secure RSS feed. So I thought this might be a good time to spread some gyaan (adapted from Web sources) about this technology that is tragically underutilized, at least in India. RSS stands for Rich Site Summary but is more popularly referred to as Really Simple Syndication. It is used to publish (suitable) Web data, along with metadata that describes the data, in a simple XML-based format. This data "feed" can be viewed by various programs including Web browsers and specialized RSS feed readers. Atom is an alternative to RSS for publishing Web feeds

RSS was designed to show selected data, such as news headlines, and provide links to more detailed data, such as news reports. But these links are not crucial if your data is limited and can be provided within the RSS feed itself, as was the case with my team

Every RSS feed contains a mandatory <channel> </channel> element, which encapsulates one or more <item> </item> elements. Each <item> element has three required child elements:

<title> - Defines the title of the item

<link> - Defines the hyperlink to the item

<description> - Describes the item

The description can be used to carry the actual data you want to publish. If your data contains special characters, including XML tags, you can enclose it within a <![CDATA[ ]]> element. Comments can be added using <!-- --> tags, similar to HTML

Your RSS feed file, which should ideally have a .xml extension, can be optionally validated for checking the syntax and then published to your web server. The feed can be updated either manually (by editing the file) or by using a Perl-CGI or PHP program to append new data to the file

Samsung Galaxy Tab 2 P3100 with Android Jelly Bean

For the last 3 weeks, I avoided reviewing my Samsung Galaxy Tab 2 P3100. Mainly because there are thousands of reviews on the Web already. Mine would not have had anything different to say. That is, until today. Because today, Samsung upgraded me from Android 4.0 Ice Cream Sandwich to 4.1 Jelly Bean (over the air, without prompting for my permission - that was rude!). The file download took some time but once the upgrade started (involving a reboot and a cute animation of the Android robot getting his stomach operated), it was completed in less than 5 minutes. And the difference is to be seen to be believed. There has been an obvious improvement in the touch screen experience. Home pages scroll faster and "press to click" happens quicker. The notifications have moved from bottom right to top center. There is a permanent set of useful icons at the bottom - Phone, Contact, Messaging, Internet, Setting, Apps that remain when you scroll between home pages. The troublesome screen-shot button has disappeared from the bottom, leaving only the ones for navigation (and the small button for the mini apps quick launch bar). The weather app and the clock seem to have merged with each other, which looks great although it leaves me dependent on the mini apps bar to set an alarm. Another issue was that I lost all my painstakingly-arranged desktop shortcuts and had to redo all that hard work. But I'll gladly accept that as a payoff for a smoother-looking, smoother-feeling user interface. Android rocks!!!

P.S.: All you guys at Google should take note... coming from a recent convert from the Nokia ecosystem, that last phrase is a solid compliment!

Skype and Port 80

I was trying to start the Apache web server installed on my desktop, to test something in PHP. But I kept getting the error "Operation failed". Even re-installing Apache did not help. I was at my wit's end trying to figure out what had gone wrong because the web server was running fine a few days ago. Then I tried running httpd in debug mode (httpd.exe -e debug). This told me the reason for Apache not starting was that some other program was blocking port 80 on localhost. But common sense told me I had no such programs running on my machine. A quick Google search later, I realized that the villain was none other than Skype. Skype allows users who are behind firewalls to use port 80 and 443 as an alternatives for incoming connections. Disabling the use of these two ports for Skype will free them up for Apache. Now I'm able to do my PHP testing. Here's the link that helped me solve the problem:

http://www.mydigitallife.info/disable-skype-from-using-opening-and-listening-on-port-80-and-443-on-local-computer/

Digicam v/s DSLR

A neighbor who plans to buy a camera soon asked me, "What is the difference between a digital camera and a DSLR? Why should I prefer one over the other?" As someone who uses a 12 MP DSLR, a 12 MP mobile phone camera and a 14 MP digicam, I wouldn't have any hesitation in recommending a DSLR. But  I wasn't really confident about the right way to answer the question, and decided to do some online research

Two very good pages I found in this regard were  this one and  this one (disclaimer: I don't vouch for their content). Based on their analysis and my own experience, I decided that the best way to present my case would be to write down the strengths and weaknesses of the DSLR, and see how the digicam stacks up

DSLR Strengths

1. Image Quality: Clearer, more "zoomable" pictures. The best digicams can match DSLRs in good light conditions but cannot beat them. In low light situations, DSLRs win 11 times out of 10

2. Lenses: Various lenses can be used, along with different accessories like filters, extension tubes, external flashes, etc. as per the situation. The same DSLR can be used to capture the pollen grains on a bee's leg and to click the crowd at junior's birthday party. Even the best digicams cannot offer that kind of adaptability

3. Accurate Viewfinder: What you see in the DSLR's optical viewfinder is what you get. Period. In digicams, the viewfinder is unreliable but what you see on the LCD screen is close enough to the clicked image

4. Manual Mode: More control over the exposure but now many digicams have started offering this

We shall ignore some other strengths that are not of much use to a newbie, such as greater ISO range 

DSLR Weaknesses

1. Price: The number one deterrent. The camera body is costly. Good lenses are even costlier. Most digicams are reasonably priced. My advanced digicam cost about a third of my entry-level DSLR

2. Size and Weight: Entry-level DSLRs are not quite unwieldy but they do weigh you down. Not suitable for morning walks and treks. Most digicams are lightweight and would fit into your jeans pocket

3. Noise: They make a "clunk" noise, which can be trouble. Try photographing a butterfly with a DSLR, especially one of the sensitive species. You can always turn off the "click" sound of your digicam

4. Complexity: The first few days, I could only use the Automatic mode of my DSLR. Experiments with Manual mode would mostly end in disaster. But then, this could happen even with a digicam
5. Dust on Sensor: The mirror that creates the viewfinder image opens and shuts for every click. So you are likely to get dust on the sensor quite often. Cleaning it yourself, though possible, is not easy

So, at the end of the day, the digicam is more affordable and easier to carry around. But if you are serious about photography and want to capture the best possible images in a given situation, go for a DSLR. That is what I shall advise my neighbor, the next time we meet

Startups and Funding

The startup I have been assisting finds itself in a bit of a tight corner financially. On one hand, we don't have enough money to expand our team because we only have a few small projects in the pipeline. On the other hand, we can't get bigger projects till we expand our team, in terms of both headcount and skill sets. Despite all our efforts, we haven't been able to attract any VCs or angel investors. So I asked myself - what is it than an investor looks for in a startup?

First and foremost is a business plan. A good business plan shows your would-be investors the company's potential and convinces them to invest their hard-earned cash in a startup. It tells them what you would provide your target audience that is different from the offerings already in the market, attracting customers  towards your firm and growing its market share. After all, why would an investor put money into a company that doesn't promise good returns

Next comes a good core team. An entrepreneur (or set of partners) may have a great idea, which has the potential to be the next Facebook or Twitter. But do they have the right mix of skills to develop the idea and start earning money? If they have a good set of people to start off with, they may be able to gradually build a strong and successful organization around it. The core team should cover all aspects of the business, from technical work to management

Last but not the least, the entrepreneur must be clear about his goal and must remain focused on it. It is easy to get swayed by trends and deviate from your business plan. For instance, jumping on to a bandwagon like Android apps just because everyone else is doing it (just an example, no offence intended to Google). Angel investors especially would be very attentive to this aspect, since they generally remain invested for longer than Banks or VC firms

Today India has many firms that provide both capital and business advice to startups, especially those in the IT and telecom sectors. Any one with a business plan that leverages the power of the Internet, but in a way that is different from the competition, has a good shot at getting funds. The impact of the recession on this sector has been relatively mild. For a budding Indian entrepreneur who follows the above rules, this is as good a time as any to attract funding

Client-side Business Analysts

By definition, a Business Analyst is someone who analyzes the existing organization and design of systems (whether business processes or IT systems) and helps to define the improvements needed. In an IT project, the BA's role is to understand the high-level requirement statement(s) in the project charter, deep dive into the client's business processes and prepare the product scope and project scope. Generally this role is performed at the vendor's side, either by the Project Manager himself or by a specialist BA who has more likely than not worked his way up from a technical role

But sometimes, especially in international projects, one finds the Business Analyst role being played by someone at the client side. This may be an employee of the client organization, or a contractor appointed by the client management to speak to their employees and note down their detailed requirements. The intention is to save the additional time and effort of requirements gathering by the vendor, by giving them everything they need to know. But if you are the PM from the Vendor organization, this is not necessarily good for you. In fact, it can do more harm than good

Since the client's BA has already given you a detailed set of requirements, their management expects you to jump right into finalizing the scope (if not executing the project). This means you or your BA cannot try and find any crucial points that their BA may have missed. Hence you are more likely to face issues with scope approvals, or worse, with scope verification. Also you miss the chance to personally interact with the client employees and understand the power structures and political relationships within their organization, which would have helped you later in the project