Thursday, September 20, 2012

My Chicago Booth experience

I get a quite a few calls about my MBA experience at Chicago Booth from prospective students, and even current students about my campus recruiting experience etc, and thought this might be a good post to any one interested in this. I was in the weekend MBA program, and got done with classes in Dec 2011. As a weekend student, I flew to Chicago every Friday evening from Birmingham, Al where I was initially living and working. The program is geared for working professionals, and most of my classmates flew in as well, flying in from all over the US - many flying for over 4 hours each way, every weekend to attend class.

Even with all the flying, I would start by stating unequivocally that my experience has been great.  The quality of students and professors at Booth is very high and I have been fortunate to make some lifelong friends. In my opinion, there is a much bigger focus on academics in the weekend program, and the depth of classroom discussions is also excellent, probably much better than that in the full time program. I am probably biased, but am also stating my opinion here. There are plenty of excellent courses, and some of them were better than others like any other school. Although Chicago Booth is known as a finance school, the Marketing and Entrepreneurship programs are top notch. I also have to say that the program was not easy - part of the reason for this was that I had no experience in Finance, Economics etc, and these subjects pushed me out of my comfort zone, but the other part of this was the students were simply very talented and hardworking, and lifted the classroom experience to a different level. There was hardly a week where I didn't have a conference call with my classmates who were all distributed throughout the US, working on some homework assignment into the wee hours of the night. Looking back, I am amazed that I put in the effort, although at the time, the pleasure of working with my friends and learning something new was greater than the exhaustion of working a full time job, juggling a family life and then flying to school. You have to have a supportive spouse if you are married, and that makes all the difference.

As a weekend student, the curriculum is the almost exactly the same as that in the full time program, and the professors are also the same.  Having said that, there are a few areas where I think weekend students do not get the same experience as others in the full time program, and this is simply due to the nature of the program, given the classes are on Saturdays. First, there are a few courses which are not offered on the weekends. This is less of a concern these days, but the exceptions are still present. Second, there are lesser opportunities to network with other students if you come in on Saturday morning and leave the same evening. As I was living in Birmingham,AL and later in Houston, Tx during the time, I would fly in on Friday evenings, and leave on Saturday evenings or even on Sundays. This allowed me to meet a lot of other students, and made my experience a lot richer.

Let me talk a little about the on-campus recruiting (OCR) process for those interested. The recruiting cycle when I went through it, started sometime in September and continued through early December. You get to meet with a ton of companies, and the level of interest in Booth students, weekend or full-time, is high. Most students who are well prepared, get jobs - again this is my opinion. There are exceptions, and the unlucky ones do manage to find something pretty soon later anyway. There are couple of things to note though. Networking and establishing relationships with alums and others in the companies you are interested in joining is an absolute must, and part-time students in general are not very focused on this - at least to the extent that full time students are. Some points I would recommend if you are thinking about OCR - First, start networking a year before you are thinking of going through OCR. Second, prepare cases with other students if you are focusing on consulting jobs. You need to do a ton, in my opinion - around 50 at least. Third, prepare for your 'fit' interview'. These three steps are crucial to being successful in OCR. And, if you are really serious, try to move to Chicago for a couple of months - I did that along with a bunch of my classmates (and we were all successful)

Feel free to email me if you want more info. Happy to help or chat about my experiences!


New product implementations - Communication issues, ROI calculations etc


One common activity in enterprises that are trying to implement a new software application internally or upgrade an existing one is to try and do some kind of ROI analysis to validate the effort. (Here, I am primarily talking about products required for the company to conduct their business). The argument typically goes like this: The application will make us faster, cheaper, allow us to produce better quality widgets etc.

However, most often, the data and analysis behind this assertion varies from a very high level guesstimate, to pure opinion.  In order to do this ROI analysis well, in my opinion, you have to start with a very simple question, yet one which could be fraught with political disasters.
What is it exactly that will make the company faster, better etc? In other words, what has changed to make the enterprise more efficient?

In most cases, one would hope that the efficiencies come from changes to the underlying business processes. However, the challenge lies in capturing the business processes and efficiencies at that level across the company, and determining the ROI. For e.g. If a sales manager is spending 5 hours entering data into a home grown CRM system, and if upgrading this system or replacing it will allow her to reduce this time to 3 hours, there is a efficiency gain of 2 hours. So what? Can we take these 2 hours and translate it to revenue gains? Can the sales manager sell more with the 2 hours she has gained? If not, what do we do with those 2 hours? Cost savings? How much and where are these savings?

Which brings me to the next issue. How do we communicate the expected changes to the affected stakeholders? Many projects fail because employees fail to adopt the new application - and a big reason for this is, they don't buy into th expected benefits. A process level analysis, showing the activities and time spent pre-implementation and post-implementation will go a long way in eliminating these issues.
Unfortunately, there are few projects that actually spend time doing this kind of analysis. The benefits  are outsized in relation to the effort needed.


Tuesday, September 18, 2012

Software development for hardware devices

I have worked on bringing numerous software products to market while in CTS, and in HP, had the opportunity to play a leadership role in the development of an Enterprise Server which is obviously a hardware product. While the similarities between software product development and hardware product development processes are striking, it is much more interesting to talk about the challenges when you have a software team working on a hardware product, particularly when it comes to QA..

In a typical software product development process, the QA cycle would involve writing test cases, opening up the web/windows application and running the tests, logging the results and tracking the bugs. This is a straightforward process if planned well. Now, this process is similar when it comes to hardware products,  but there is one big obstacle..You need the actual physical hardware to do the tests properly and there are large dependencies on the hardware teams. Coming from a pure software product management background, this was a big change for me :)

If you have a bunch of software teams working on various hardware components - in my case I had 7 different teams writing software for the enterprise server that we were building, and they were distributed geographically - well, then you need a huge QA cycle, and the interplay between monitoring requirements, schedules, costs and maximizing productivity becomes particularly challenging. Some unique questions to ponder while designing the software testing processes for hardware devices:

1. Dependencies between the software and hardware development teams - this is important in hardware devices as the physical development might not proceed linearly, and will thus affect the software testing.
2. How many physical devices should you order for each test? Does the hardware development timeline align with this? Have you allocated enough budget for the build and shipping of the different physical devices?
3.Communication processes between the different teams - this is always difficult, but gets exponentially complicated when you have teams in China, India, the US etc. and some are hardware folks, and some are software and thus speak different languages, both literally and figuratively.
4. What are dependencies on external vendors? Many hardware devices align to release schedules of chips and processors that companies like Intel develop, and this may or may not align with your schedule

There are more issues one should consider, but these are the big ones.