The key to conducting a successful project management interview is to keep the context situational, practical and application oriented. My 2 cents on this topic:

The role play game : This is my favorite style to judge people management and crisis management skills. People management is an in your face, full contact activity. Playing the role of an obstinate developer who refuses to stay beyong 5 PM, see how your candidate approches the situation. Take him through increasing levels of frustration throwing all kinds of excuses of why you *have* to be leaving at 5 PM. Step out of the role play at strategic points to get feedback on why something was done/said. A good manager will *never* give up and will always find a way.   

The constraints game: Throw up a situation that is impossible to manage successfully. Say a team with 80% of freshers need to deliver a complex application under aggressive timelines at a fixed price. Let the candidate choose which constraint he wants to make flexible and how he would go about engaging stakeholders to drive consensus. 

The "Describe your day" game: Good planning goes beyond making a good project plan. Give a roster list of activities/issues for the day and ask the candidate to plan out the sequence and action plan to get the tasks done. The list should encompass multiple aspects of project management and should force the candidate to make fine judgements, delegations where needed, push backs and tradeoffs. Here's an indicative list:

- Check on the  progress of the onsite requirements gathering excercise. Note :There is a 3 hour time lag.  

-One developer has reported that his task is slipping. This task needs to get done latest by tommorrow. He has sent an SMS reporting sick and has subsequently switched off his mobile.  :-)   

-The delivery manager has called for a metrics analysis meeting first thing in the morning. The invite was sent only last night and has come as a surprise. Your metrics are nowhere in shape.

-The SQA is pushing for some process document to be reviewed and there has already been an escalation on this. 

-The build process is very inefficient and this has been a long pending issue, but the architects and the leads have not had the time to look into this.

-An intermediate milestone needs to be pushed by 2 days and the milestone is a week away.

-There is an email with some change requests that have been logged by the client. You have been requested for a revised plan by EOD.

Avoid theoritical questions: "What is timeboxing ? ". Unless, you want to hire someone for writing a manual on project management, give such questions a miss. Instead relate the questions to acutal projects the person has worked on. "Give me 2 high impact but low probablity risks from the project you managed last ?" is better than "How do you manage risk in a project ?"  

Certifications mean jackshit:  It is possible for someone who has never managed a project to score high on certifications like PMP or PRINCE. If your HR uses PMP as a resume "filtering" criteria, you might end up rejecting some great managers and letting in some lousy ones. 

MS Project hands on session: Any manager can put together a plan in MS-Project. How many actually track ? How many understand task types and understand when to turn off effort driven scheduling ? If you need MS Project skills in your hire (you will) keep a MSP open in your laptop and let the candidate have a go at some excercises. If he baulks reject him.

Technology expertise:  Ask questions in the technology area the candidate belongs to. A project manager without technology exposure is severely hadicapped in multiple ways. He cannot validate estimates, will not have a true appreciation of problems and most importantly will not have the respect of the team. If he protests in the face of such queries, simply reject him.

There is no "right" answer to many of the strategies mentioned above. What matters is the though process. Which is probably why hiring managers is an art!

The People manager: A master at the art of delegation, often delegates even the task of delegating! Typically very process oriented, hates getting into details and thinks that the solution to every problem lies in getting the right person to work on it. Creates layers of abstractions in the hierarchy that allows him to escape from details. Loves spending time on administrative issues and is very metrics oriented. Has difficulty in earning the respect of the team, but his political savviness ensures he does well. Favourite deliverable: The status report! Punch line : " I have 100 people under me."

The Techie manager: Typically a good developer back in the day, is a little bit of a bull in the china shop. Loves getting his hands dirty and secretly hates his managerial job and tries to delegate "dirty" process related stuff. A hero at the grassroots level, but typically lacks the political savvy. Known to ridicule the people manager is also proud of his technical skills. At times wonders if he should switch to being an architect. Favourite deliverable: The design document. Punch line: " Who are you talking to ? Show me the code").

The MBA manager: Stuck in an job that requires no MBA'ish skills, is confused and suffers a constant "stuck in the middle" feeling. Itches to get into client facing roles and is deluded into thinking that sales is the ultimate nirvana. Loves domain intensive projects and typically fights with the business analyst. Tends to be more people oriented than task oriented and loathes technology and considers it "dirty". Favourite deliverable: The requirements spec!  Punch line: "The big picture is the only picture". 

Execution excellence has always been the cornerstone of the services industry. In the last few years we have had domain knowledge and high end consulting with it's different flavours added to the mix. But is anyone talking of technology ? Does the red blooded technocrat have a high flying career path ahead of him or will he necessarily face a mid career crisis ?

Profit drivers:

Bill rate, Utilization rate and Onsite/offshore mix: How many software services projects demand a principal architect ? Not many in my experience and even if needed, only for short duration upfront work. So even if the bill rates are high, the overall tangible revenue contribution would remain low due to lower utilization. Sometimes, senior architects get staffed into roles that do not do justice to the skills or aspiration of the person (doing some POC's, "r&d" or "MVC" type design) . Hardly a good situation!

How can the hardcore technocrat find his true calling?  

• Reduce cost through reusable components: Services companies could use senior technocrats to "envision and execute" in house productization projects aimed at directly lowering the cost of development. Eg. Creating a common engineering services library that can be used to provide the foundation layer for J2EE projects in the company. This hits the bottomline in a tangible fashion by reducing cost and bugs.  
• Convert buzzwords to frameworks : The industry is awash with jargon. Every client wants their project to have SOA, BPM, BAM and what not. How can a Weblogic or a Tivoli be actually used to enable these buzzwords on the ground ? Proactively creating framework code to enable these buzzwords would again directly hit the bottomline and the reusablility would more than justify the investment. The key is to have a project independent architectural group that can drive such efforts.
• Using technology innovations to drive existing account growth: How many times does a development team proactively suggest value adding ideas to the client ? Most dev teams simply don't have the time especially in a cost arbitrage driven services model. Bleeding edge technology can be a potent tool to create fresh revenue streams in an account. Check out AJAX. Definitely something that can be compelling to many clients. Again the key is a project independent technology group that can consult with project teams.
• Penetrate new buying centres: Typical sevices sales teams focus on the executive management. Fair enough! But in many companies, especially product companies seeking to outsource, the buying centres are typically technology savvy. Having a senior tech veteran supporting the sales team from onsite can be crucial to gaining customer confidence during the sales cycle.

How can management help the cause ?

• Billability mindset to an investment mindset : Which client will pay for an project independent technology group ? This is a fair question in a services company, but is not conducive to the growth of the technocrat.
• Create an R&D budget however small. This will provide the resources need and create the right climate.
• Infuse the right DNA : Selectively hire from product companies to create a small base of people who have right credentials.
• Incentivize sales and account management to drive growth through technology innovations. Once the topline benefits become clear, the business case will be easier to sell to all stakeholders.
• Staff a few senior technology professionals into onsite sales support with a clear mandate to influence the technology savvy buying centres.
• Incentivize project management to deploy the frameworks created by the independent technology group.
• Incentivize quality to create metrics to track the contribution made by the independent technology group.

The value of any software or hardware standard is heavily dependent, among other things on the size of the network of users who use applications that leverage the standard. Customer willingness to move from one product (or standard) to another depends on :

• The ability and the cost involved in migrating legacy assets created using the previous standard *without* loss of value.
• The extra, tangible business value add that the new standard can provide over the existing one. In other words is there a business case?

Market Share distribution:

Number of MS Office users : 400 million +

Rest of the crowd                  : 21 million

Legacy Asset base (number of documents) :

MS office                               : Hundreds of billions

Rest of the crowd                 :  Maybe a few billion if we are lucky. 

Now, given the status quo, let us list down the drivers that attempt to change the status quo and analyze the impact.

• MS Office to support ODF: MS Office will support plugins that would allow saving MS office documents in ODF format and allow MS office to read ODF documents. Now, it is impossible for a relatively new standard like ODF to incorporate the *ton* of features the MS Office supports with two decades of evolution behind it. This would just mean that the average corporate user who saves an MS Word document in ODF and tries to open the same using an Open Source ODF document reader will well…not do it the second time.
• Introduction of Office Open XML: A very smart and classic Microsoftish move. Embrace an "open" format (like XML) without compromising on market postion in any way. Office open XML would straight away defuse critics who claim "binary and proprietary" formats are being used by MS. At the same time it allays government concerns on security and transparency by allowing legacy MS office documents to be stored in XML that can be read by any XML reader (not just by the office suite) *but* the catch here is that third parties cannot create commerical products that leverage Open XML. The implication is that only the low end of the market (educational) will shift provided of course third parties can keep pace with the Microsoft controlled Open XML. Everytime MS changes the Open XML spec, other vendors will play catch up. Ridiculously tough terms to compete on.    
• Open XML to ODF convertors: This would again suffer from loss of data upon conversion because Open XML supports the full set of MS Office features while ODF doesn't. Even if SUN or IBM comes up with a free SOA service to do the conversion, the situation would not change as loss of legacy data is something few corporate users would tolerate. However, reverse conversion from ODF to Open XML would mean the user base of Star Office and other competitors could move over to the Microsoft bandwagon, provided of course there is no loss of data which is a better possibility given that Open XML being richer is possibly a super set of what ODF provides (after all people have been playing catch up with MS Office and trying to create clones for years).

Conclusion: ODF is unlikely to hurt MS Office market share in any significant way. In fact, the MS counter move of Open Office XML might actually help Microsoft fight criticism and gain some brownie points if not further it's market share. 

There are great services companies and also rans. There are great clients and terrible ones. In this writeup, I try to put down some parameters to identify a "goodness" index for clients.

Team capability growth value: Does the kind of work the client the provide improve my team's capability ? Will a fresher with one year on the project be able to do work equivalent of someone with two years in an "average" project ? Capability growth can be measured on managerial value, technology value and domain value dimensions.

Team career satisfaction index: Clients who demand that the team be overskilled will score negatively on this dimension. Overskilling a team, besides hitting margins, would cause people issues and increased attrition.

Commercials : This one is a no brainer. Better margin clients with decent volumes deserve to be treated like kings.

Strategic value: The client's brand name is so strong that a postive referral would mean plenty of follow through business in the client's vertical. Walmart would be a strategic client in the retail sector. It is easy to imagine a Two Guys falling for Walmart credentials. "Strategic" could also mean the first entry into a geography or a vertical.

Revenue quality : What percentage of the current/future revenues come from high end consulting ? Having a huge maintenance portfolio might be good from a revenue stability perspective but does not help the cause of revenue quality.

Relationship quality : High trust, high value relationships typically translate into a high share of the IT wallet even in a multivendor situation. Some clients are so distrusting that they sometimes put staff into the team to "snoop" around, evaluate skill sets and generally keep a tab on this. Not a good situation to be in and typically indicates a tactical client mindset.

Transferability of skills: This point is related to team capability growth and team career satisfaction, but is different in the fact that we are referring to the transferability specifically. Astronomical bill rates for a proprietary in house technology could be debilitating once the project is over, with months spent on reskilling. 

Solution breadth: How many services out of our portfolio is the client currently using? Is it just a one off maintenance project or a mix of maintenance, custom development, package solution development and consulting. Greater solution breadth works like portfolio diversification and reduces risk and increases client switching costs.