Delegate, and bite your lip, but don’t stop communicating.

One of my greatest frustrations at being a manager and solution designer is coming from a software development background and having to delegate coding tasks.

So why do I delegate and get frustrated.

I delegate because I do not have the time to do everything I want to get done. I have to rely upon others to do what I once could easily have done. Delegation and communication is what makes an effective team and team leader.

My frustration isn’t because I think I can do it better (well maybe it is sometimes), it occurs when someone finds excuses to not do the job properly – this can be colleagues at work or a teenage son. If you are going to do a task, even if it is for a demo then do the work properly and as if you are going to sell it later – in the case of software this may well be the case and so you want to avoid financial and technical debt.

So while a may I feel like telling people to “just get on and do what I asked”, this wouldn’t always be effective. Delegation relies upon effective communication, and sometimes this means cajoling someone into delivering what you want rather than what makes their life easy, this can be quite frustrating especially if you have to keep doing it.

Enabling someone else to do a job requires

they know what you want

they have the authority to achieve it

they know how to do it.

 

If you feel above three items have been done then it is down to the person you have delegated to to communicate effectively with you, especially if they are unsure of their responsibility and what is expected of them. Otherwise the task is at risk of failure.

Every article you read on project failures should mention “lack of communication” as one of the causes. Poor requirements lead to misunderstanding, lack of developer feedback and demo’s leads to misunderstanding – especially in agile projects.

So you can delegate and bite your lip when getting frustrated but don’t stop communicating otherwise you are at risk of not delivering the task.

You can delegate the work but not the responsibility!

 

Bibliography

 

http://www.see.ed.ac.uk/~gerard/Management/art5.html

http://www.bizhelp24.com/employment-and-personal-development/the-art-of-delegation-2.html

http://www.talkbiz.com/digest/emt17.html

http://thompson-web.blogspot.com/2008/04/project-estimation-duration-effort-and.html

Design Methodologies - where do you want to spend your money?

I recently revisited articles on design methodologies, specifically TOGAF (The Open Group Architecture Framework) and Agile methodologies. Initially, I thought that both approaches contradict each other and so could not be used together. However, like writing software you combine best practices from different methodologies that meet your project requirements, improving the chances of a successful project.

I'm not going to try and pretend to be a TOGAF professional, I have an awareness of the framework and have never used it end to end. I believe that if you are going to design software then you should at least be aware of frameworks such as TOGAF and alternatives. A good start on agile is Martin Fowler "The New Methodology" and "Can SOA be done with an agile approach".

TOGAF combined with Zachman framework is a top down design methodology and provides an excellent mechanism for eliciting requirements and providing a framework for communication in a common language, but as Fowler states big up front design can become very expensive. Also, it can lead a project to not deliver what is required by the business when the system goes live, rather it delivers what was required initially. The difference may well be dramatic.

A good reason for top down design is to do with procurement and the need to identify appropriate commercial products to use, a focus of TOGAF. Large organisations want to outsource at fixed price and the vendor organisation doing the work wants all the details up front to have the best chance of delivering the project at a profit. Again, Fowler makes a good point about the "Adaptive Customer" and how customers need to be adaptive in the way they engage with vendors. Although from my experience of being both the vendor and using vendors to do work there is never an ideal approach. A vendor wants to make as much money as possible while the customer wants to control the scope and spend as little as possible.

So where do you want to spend your money?

Up front with lots of design, then on lots of change requests and the end result will be lots of documentation that in theory should reduce the maintenance overheads, keeping the future costs down.

The alternative is relying upon highly skilled and talented  software engineers who may or may not use a silver bullet, document the code or write any design material thus making maintenance harder for someone un-familiar with the code.

I have seen both top down and bottom up methodologies succeed and fail to varying degrees. It is my opinion that success is based upon good judgement and adaptability at the beginning and during the project on the part of everyone involved.

Combining the requirement analysis and control features of TOGAF with an Agile methodology, and the use of PRINCE project management looks like a good combination as long as you are adaptable in selecting the parts that make most sense for the project you are working on.

AltioLive enabling the enterprise mashup

The AltioLive product provides both server side and client side architecture. This enables a secure load balanced mechanism to deliver data to and from a client. The client can be a user interface or another system.

What does this have to do with AltioLive? It has been the belief at Altio for a long time that a mashup does not have to be visual, but can be associated with data as well. For effective delivery of business solutions a product needs to be able to deliver data from multiple originating sources and the user should not need to know or understand the source of the data. AltioLive provides composite components to create visual business solutions and on the server side aggregated data feeds, this provides an effective mechanism to deliver browser based applications that interact with data from multiple sources.

A recent article in SD Times by David Linthicum provides a good overview of this, with the visual mashup described as

"the ability to change the manner in which a visual interface behaves by mashing it up with other content or services"
(Software Development Times, June 15 2008, page 37)

The article describes a non-visual mashup as 

"the mashing up of two or more services to create a combined application, or integration point to service a business process".  (Software Development Times, June 15 2008, page 37)

AltioLive composite controls enable a designer to take several existing components and package them together as a new business component or enterprise mashup widget. This means a library of re-usable components can soon grow and result in reduced development time for future solutions.

The AltioLive aggregated data feed provides a simple yet powerful workflow for retrieving data from disparate data sources. It is possible to use data attributes from one source as a parameter for the retrieval of data from another data source, execute multiple request in parallel or sequentially and stop execution if a failure occurs. This is the non-visual mashup.

Whatever you want to call this approach the ultimate aim is to deliver an application that makes the end user more effective in delivering business benefit as quickly as possible, without losing sight of maintainability.

The key factors of SOA/enterprise mashups as described in the article are:

• the ability to place volatility into a single domain, thus allowing for changes and for agility
• The ability to leverage services, both for information and behavior.
• The ability to bind together many back-end systems, making new and innovative uses of the systems.

This is something Altio continues to deliver through the AltioLive product as innovative ideas.

 (This article was originally posted to http://www.altio.com )

Project estimation (duration, effort) and Project Failure

Several times recently I've been involved in discussions about project estimation, sometimes with project managers and other times in general conversation about project failure. Here is my opinion on why both duration and effort are important in estimation and neither can be ignored. This my personal opinion and every project and organisation may differ and should be treated appropriately by using the correct project management and software design methods.

Background on Project Failure

The UK National Audit Office summarises the common causes of project failure as:

NAO/OGC Common causes of project failure

1. Lack of clear link between the project and the organisation's key strategic priorities, including agreed measures of success.

2. Lack of clear senior management and ministerial ownership and leadership.

3. Lack of effective engagement with stakeholders.

4. Lack of skills and proven approach to project management and risk management.

5. Lack of understanding of and contact with the supply industry at senior levels in the organisation.

6. Evaluation of proposals driven by initial price rather than long term value for money (especially securing delivery of business benefits).

7. Too little attention to breaking development and implementation into manageable steps.

8. Inadequate resources and skills to deliver the total delivery portfolio.

I define project failure as one that either goes over budget, over schedule or both, or fails to deliver what the stakeholders actually expected. Most media attention focuses upon costs and timescale, and let's face it project failure is not isolated to IT projects - Wembly Stadium, 2012 Olympic Bid, the Millennium Dome were not IT projects. Until recently Heathrow Terminal 5 was hyped as the way to run projects (Agile), yes it may have been on time and on budget but in the end it failed to meet stakeholder expectations – the users of the terminal were far from happy and executives lost their jobs.

The importance of duration and effort in estimation

When I ask for estimates I always ask for two numbers the duration and effort – just so that it is clear to me how much the work is costing and how long it will take to deliver. When it's an external contractor I'm interested in duration and the bottom line cost not the effort, so this note applies to internal projects.

Effort is the direct cost of running the project and I would expect a project manager to be able to break down the estimate into deliverables/artifacts/tasks/function points – for me they are all the same, a quantifiable item of work. The quantifiable item of work can be listed in a Scrum burn-down list or an item in a project plan, but the project plan and burn-down need to take into account duration, more on this later. This effort provides the basis for future estimation for performing the same or similar piece of work. Using a well managed timesheet system enables project managers to make better estimates for future projects based upon projects of similar size, complexity, and industry type (OK it's not quite that simple but I'm not writing a thesis here).

The effort estimate will be affected by a number of factors e.g. sick, holiday, training, going to meetings not related to the project. All the daily tasks that an employee will be expected to undertake. This is what makes up the duration estimate of the project – the bottom line is "how productive is a person each day in your organisation". So if the effort to complete a project is 100 man days but an employee can only spend 80% of their time doing productive work then the duration is 120 125 days to deliver the project.
(UPDATE - Oops. Basic math error, should be 125 days.)

Estimating duration and effort means that a project can meet schedule and costs, but accurate estimation is only possible with historic data – which is why using accurate timesheet systems is needed.

Most people in software hate completing timesheets. I know this because I did when I used to cut code – it's an unnecessary distraction and stops you getting on with doing fun things like designing and writing software.

If there is to be any professionalism in software engineering then developers and testers etc need to understand the importance of estimation. The problem is that every time a developer enters 8 hours development time when they really worked 12 just sets false expectations for the project manager and stakeholders. The next time a project is estimated the project manager looks at the timesheets and thinks "if I pay for 2 hours overtime I can get more from my team" and the team end up working 14+ hour days. OK, nobody wants this and I firmly believe in the Agile 8 hour days – even if I don't apply what I preach, but the responsibility lies with everyone on a project to ensure effective project estimation.

Applying the appropriate estimation

At Altio PRINCE and Agile (Scrum) techniques are used to deliver projects. PRINCE provides the control and communication, the use of burn-down charts and daily meetings ensure project duration and deliverables are constantly monitored.

Effort estimates are used to calculate cost and this is where it is important that staff book their time accurately otherwise a project can fail on cost because staff spent most of their time on work that was not project related and so should have booked their time accurately (and I do draw the line at having a "Rest Room" or "Cigarette Break" task). For Altio projects we use several estimation technique – the simplest being a spreadsheet that applies triangulation estimation using best, most likely and worst case scenarios.

A project manager then takes the estimated effort and populates a project plan with tasks and adjusts staff availability to get a duration.

To monitor a project in progress then duration is important and using burn-down charts with staff providing daily estimates of how long it will take to deliver being the key. This estimate by the team members is pure duration, if the person is only managing to work 2 hours a day and there is 10 hours of work left, then the duration is 5 days. It's down to the project manager to manage why the person is only doing 2 hours a day and to manage the risks that this dilution of work effort causes.

Constantly changing estimates

It is important to constantly review project in progress and adjust estimates based upon knowledge from previous projects and deliveries. Using PRINCE gateways as the time to re-estimate is important, as it is the time to provide the details to the stakeholders for them to make decisions.

Conclusion

There are lots of debates online about project estimation and ultimately every project will be different because of the people working on it, the technology being used and the expectations of the stakeholders.

Software projects are all about developing new and innovative systems otherwise we would just buy the most appropriate product off the shelf. This means there is no blue print for accurate software estimation – software engineers are not laying bricks to build a house so there is no way to say how many bricks per hour a person can lay and apply that to all projects (the analogy being lines of code = bricks).

REFERENCES

Listed below are a number of useful links and documents that I use for reference.

1. http://www.itprojectestimation.com/estrefs.htm
   
2. The Holy Grail of project management success, http://www.bcs.org/server.php?show=ConWebDoc.8418 accessed March 2007
   
3. Wembley Stadium Project Management, http://www.bcs.org/server.php?show=ConWebDoc.3587, accessed March 2007
   
4. Olympic bid estimates, http://www.telegraph.co.uk/sport/main.jhtml?xml=/sport/2007/02/08/solond08.xml, accessed March 2007
   
5. UK Government PostNote on NHS Project Failure, http://www.parliament.uk/documents/upload/POSTpn214.pdf, access March 2007
   
6. UK Government Post Note on IT Project Failures, http://www.parliament.uk/post/pn200.pdf, accessed March 2007
   
7. Project Failure down to lack of quality, http://www.bcs.org/server.php?show=ConWebDoc.9875 , accessed March 2007
   
8. Steve McConnell, Rapid Development, Microsoft Press,1996
   
9. Martyn Ould, Managing Software Quality and Business Risk, Wiley,1999
   
10. Art, Science and Software Engineering, http://www.construx.com/Page.aspx?hid=1202 , Accessed October 2006
    
11. Simple and sophisticated is the recipe for Marks' success, Project Manager Today, page 4, March 2007
    
12. Ian Sommerville, Software Engineering 8^th Edition, Addison Wesley, 2007
    
13. Barbara C. McNurlin & Ralph H. Sprague, Information Systems Management in Practice 7^th Edition, Pearson, 2004
    
14. Overview of Prince 2, http://www.ogc.gov.uk/methods_prince_2.asp, Accessed November 2006
    
15. The New Methodology, http://www.martinfowler.com/articles/newMethodology.html, Accessed October 2006
    
16. The Register – IT Project Failure is Rampant http://www.theregister.co.uk/2002/11/26/it_project_failure_is_rampant/, accessed October 2006
    
17. Computing Magazine – Buck Passing Route of Project Downtime http://www.computing.co.uk/itweek/news/2183855/buck-passing-root-downtime, accessed February 2007
    
18. National Audit Office – Delivering Successful IT Projects http://www.nao.org.uk/publications/nao_reports/06-07/060733es.htm, accessed March 2007
    
19. Successful IT: Modernising Government in Action, UK Cabinet Office, page 21
    
20. Project success: the contribution of the project manager, Project Manager Today, page 10, March 2007
    
21. Project success: success factors, Project Manager Today, page 14, February 2007
    
22. Six Sigma Estimation http://software.isixsigma.com/library/content/c030514a.asp , accessed October 2006
    
23. Analogy estimation http://www-128.ibm.com/developerworks/rational/library/4772.html, accessed January 2007
    
24. Symons MKII Function Point Estimation http://www.measuresw.com/services/tools/fsm_mk2.html, accessed March 2007
    
25. COCOMO estimation http://sunset.usc.edu/research/COCOMOII/ accessed January 2007
    

End of January beginning of February

Boy, how time flies, I can't believe it's the middle of February already and the year is moving fast. The team working on Altio have released Altio 5.1.4 which is probably the last release of Altio 5.1 before we release Altio 5.2. Just to make me even busier I spent the first week of February in Boston initiating our latest project for Paragon using PRINCE project management and building a system using Altio with a SOA architecture.

The project kick off in Boston went really well with the documentation being received extremely well so now all involved in the project know about:

• the vision
• the objectives
• delivery gateways
• quality plans
• project tolerances
• staff involved

All because we have a Project Initiation Document (PID), which while it was hard work to produce I hope will provide value through the project lifecycle by ensuring the project is delivered on budget and on time.

Some in the teams are horrified at the amount of documentation we are producing to start our new projects, while we're all keen to do PRINCE project management now it is understood I feel I have a lot of pressure for it to succedd as it's my idea.

Why is the organization adopting a formal project management technique? Well it's because we want to provide effective communication to all stockholders in projects and to remove as much ambiguity and as many assumptions as possible that are typically made at the beginning of the project.

For the people doing the clever work of writing code and delivery functionality there will be little change, we will continue to use Agile methodologies.

In the end it means people in the company can continue laugh about my Burndown charts as well as now laughing about delivery Gateways. Ultimately the quality of our software is improving along with the ability to better predict the delivery dates of our projects and if testers and developers morale is kept high by laughing at me I can't complain :-) .

While the project will be a major challenge everyone is keen to see it succeed as it brings together everything Altio is about, a graphically rich and interactive front end with a Service Oriented Architecture (SOA) at the back-end. When Altio 5.2 is released (due May) users will have the ability to make use of Altio's data mashups as well as screen mashups - we aim to really challenge the idea of what makes a RIA and set the benchmark high.

So Altio 5.2 is well on it's way to being delivered in May and will bring a whole new designer and set of controls... I will add more on this in a later entry.

The importance of estimation!

An article on the importance of lines of code caught my eye the other day (Why is it useful to count the number of Lines Of Code (LOC) ?). I personally feel that the use of lines of code for estimation has several issues.

• Complex loops in code vs form code, it is possible to have a few complex lines of code in a loop and lots of code for generating a form. Verifying and fixing a bug in the loop may take a long time, while a fix in form code may take very little time


• What do you do about auto generated code produced by wizards? I would like to think that the code will always work so do you need to include this in the calculation. But, will generated code always work in the context of the surrounding hand crafted code


• What about abstracted definitions. For example in Altio much of the logic and screen definition is implemented as XML definitions and executed by the internal engine. The same is true for Adobe Flex and many other RIA development tools.
  

My preference, and idealistic, approach is to use a combination of several estimation techniques. Use Function Point Analysis (FPA) to determine the high level estimate (this works well for abstracted definitions). The FPA can then be used to generate an equivelant Lines of Code (LOC) estimation, this would be determined by relating the abstract definition to the equivalent Java code or C++ code (or any other language, users choice). Finally the LOC can be used in a structured estimation platform such as COCOMO which allows you to define the complexity of the system to produce and estimated cost and duration, finally confirm this all using Triangulation Estimation. I never seem to have time to do all of this and so feel the approach is best kept for large projects, or ones where you don't want a lot of explaining to do at the end of the project when it's late.

In my experience the Agile technique of using expert judgement and Triangulation Estimation will work OK. Well let's face it you get a pretty good 99% accuracy for the number of days effort to deliver.

In my opinion, however you perform estimation is a matter of choice, the important thing is to record the results learn from them and apply past experience to new estimates. Unless you purchase the software off the shelf or use past code and modules you will always be in new and uncharted territory, so how can you accurately estimate the distance you have to go to get where you want to be. Plus, users will always move the goal post making the original estimate nonsense!


Books by Steve McConnell
I've never read the book Software Estimation: Demystifying the Black Art but I have read Steve McConnell's other books Radpid Development and Code Complete both excellent books, and so assume Software Estimation will be equally as good.