Development Costs and Technical Confidence...

Micro-management is often the adversary of creativity and progress; with progress constrained by the rate at which the micro-manager reaches their own level of comfort and understanding.

This applies to technology (software) programmes, even the implementation of pre-pack solutions like OBIA!

For the manager, it's important to understand the RELATIVE impact of software development challenges, when you're delivering solutions driven by software. Why the problem is easy or why it is hard, has a profound impact on programme planning and budgets.

This can greatly increase cost for enterprise programmes, increasing the cash burn rate. For a start up, getting this wrong can be fatal!

Modern day project management methodologies must shoulder some of the blame for producing the pure 'Microsoft Project jockey', but the better manager develops a certain curiosity for software solutions that makes them more able to anticipate difficulties ahead.

As a non-technical manager in these situations, a level of questioning for your development staff is crucial. Try not to make the questioning static, like the real exchange I had recently with a client below:

Manager: That looks technical, what are you doing?
Developer: I'm re-purposing the scripts so they work in both non-clustered and clustered environments!
Manager: That's not something I can help you with, sorry.
Developer: Err... no I guess not!

Questions should be designed to tease out why certain tasks in the solution are important and how they contribute to the overall solution. A better set of questions might have been:

Manager: I understand you're working on X, is that what you're doing just there?

Developer: Not X just now, I'm working on re-purposing the scripts so they work in both clustered and non-clustered environments.

Manager: OK, I'm a little unfamiliar with that work. It sounds important, perhaps you can tell me more about the implications of this?

Developer: Sure... BLAH BLAH BLAH  
 

This level of questioning is extremely important for good project (programme) management!

Once the manager becomes confused by technical complexity, however, they revert to questioning the validity of technical tasks in a plan (solution). This level of questioning can be a waste of time!

As a non-technical manager (read start up CEO working with technical staff), keep in mind what are you trying to achieve by asking these questions...

    - enough understanding of the challenges in your project (programme)

    - a greater appreciation of the capabilities of your technical staff

    - greater control of cost

Recognise, however, once technical aspects become unclear this makes them NO LESS valid. Better developers will have some understanding of the planning and costs you're trying to control.

Keep your questioning open and you'll gain the trust of your developers!

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.

Due Diligence for Enterprise Software Programmes...

A recent client had some of the usual problems which come with large enterprise software implementations, here's my take on some improvements to consider:

1. Too many systems integrators (SIs) - if, like economic theory, we assume free trade benefits all parties then maintaining open exchange of ideas and expertise is crucial; recognising the enterprise programme will benefit only through collaboration amongst dependent parties. Theoretically many SIs on a project should compete away differences to leave an implementation of the greatest benefit to the client, but this has long been disproved by the 'power elite' theory. Most often SIs seek absolute power advantage over one another in their relationship with the client. Projects suffer, not just economically, where the client is unclear with SIs over division of roles...

2. Off-shoring tasks on the critical path in a development lifecycle - this can work, but importantly the offshore team should have some understanding of the business area for whom they are developing, the stronger the better. As a programme management team the answers to the following questions about the capabilities of your off-shoring team are helpful to clarify:

• If using an SI off-shore, are their goals suitably aligned with the programme?
• Where difficult development challenges arise, can the offshore team think critically to resolve them?
• Are their solutions of genuine benefit to the client?
• Are you getting them for the right price?
• Even if you've answered 'Yes' to these questions, ask yourself 'Does all this sound too good to be true?'

There's a distinctly Marxist undertone to the off-shoring phenomena. As an employee of the SI assigned to the client, it's understandable you might begin to feel a little exploited where its clear the singular reason for your presence is cost reduction; but poor alignment of goals produces low productivity; while rising wages in traditionally offshore locations are forms of worker revolt.

An offshore strategy can become increasingly difficult to justify...

3. Hand-offs between competing SIs engaged in the release and testing process - competing systems integrators were engaged to separately handle release and configuration management, where initially there had been one. These ITIL aspects of any programme are so closely related, introducing a hand-off in this area mostly adds time, without bringing efficiency; while the use of competing SIs here brings an unnecessary period of professional 'sabre-rattling' as all parties are encouraged to get along well for the benefit of the client. Keep it simple here; there are hidden costs in too many hand-offs!

4. When the going gets tough, which team members stand up - under time pressure, or faced with challenging tasks is the client still able to rely on all the team members to continue getting the job done? It's under these circumstances the quality of staff is revealed:

• Do they look for the right answer, or the quick answer? These are often not the same.
• Can they produce suitable quality despite added pressure?
• Is the work well documented and
• Can they still transfer the knowledge to others?

5. SIs over-stating the capabilities of their consultants (that never happens ;-) ) - Sales and the 'spin' surrounding the capabilities your SI can deliver are part of the territory, but, like hiring employees, the client would do well to consider ways of testing the consultants they end up saddled with:

• Despite the sales pitch, does the individual consultant have the basic skills required?
• How well do the consultants interpret the information provided to them?
• When confronted with a challenge would the consultant choose the 'quick fix' or the 'best fix'?

Finally, question if the client has the right skills to competently assess the quality of the consultant. Without that, your programme will be in trouble.

Its important to remember that Adam Smith's view of capitalism - where the individual rises above their self-interest for the benefit of others - does not apply here. You'd do we'll to get an unbiased view when starting your programme.

I write a blog under the pseudonym DR. OBI. Feel free to get in touch with me about your programme. You can find me here Justin Townsend.