Brisbane Lifestyle

Successful Project Management

2010-01-17T08:22:00.001+10:00

I keep noticing that everyone claims to be successful and, more often than not, sucessful only...
How good someone really is who has never experienced failure?

We all have strengths and weaknesses, and this means we perform better in some situations than others.

Have you ever noticed that when their is a problem (and there's always one), most consider self as being outside of the problem, while everybody else considers you as being part of it?

Sucessful people take ownership of the problem at hand.

The under-estimated benefits of components

2009-09-12T17:02:00.004+10:00

Components Based Architecture has been formalised and publicised by UML-RUP more than 10 years ago, and the benefits of this approach are still unknown or under-estimated by most.

It escapes me how, in the 21st century, enterprises can ignore the return on investment (ROI) that can be achieved with components.

The most commonly missing piece in the software engineering puzzle today is the architecture document. I keep seeing projects after projects documenting detailed designs after gathering the requirements and no architecture.

When no components based architecture exists, Managers are reduced to finding and selecting solutions at project level.
With well documented components, encapsulating meaningful functionality, it is for example possible to:

Find Commercial-Of-The-Shelf (COSTS) solutions for one or several components.

Outsource the development of low added-value components.

Reuse components from other applications within the company.

Components are however a science and there is more to it than what meets the eye...
See previous article RUP - Component Based Architecture

Agile Project Management with Scrum

2009-07-01T20:04:00.004+10:00

About Scrum I like the philosophy and:

Feature prioritisation sessions
30 days (undisturbed) iterations
Functionality presentation sessions
Self-organising teams

In short the principles are as follows:

All management responsibilities are divided between 3 Scrum roles:

The Product Owner focus is focused on Return On Investment (ROI)
The Team is responsible for developing functionality. Teams are self-managing, self-organising, cross-functional and they are responsible for figuring out how to turn Product Backlog into an increment of functionality.
The Scrum Master fills the position normally occupied by the Project Manager. He is responsible for the Scrum process. Like a sheep-dog, he's responsible for keeping the flock together (focused) and keeping the wolves away (undistracted).

Each Sprint is an iteration of 30 consecutive calendar days

A Sprint starts with a planning meeting, where the Product Owner presents the highest priority Product Backlog (4 hours) and the Team plans out the Sprint (another 4 hours).
A Sprint finishes with a Sprint review meeting (4 hours), where the team present what was developed. Then the Scrum Master holds a Scrum retrospective meeting with the team.

Artefacts:

A Product Backlog lists the features with estimates, associated Sprint and remaining work (days) - maintained by the Product Owner
A Sprint Backlog lists the tasks, which the team defines for turning the Product Backlog they selected into an increment of functionality, associated with the Originator, the person Responsible, the Status and the hours of work remaining - maintained by the Scrum Master -No Gantt-chart

Rules:

A fairly complete set of rules can be found here: http://www.agileadvice.com/archives/2007/05/scrum_rules.html

Get the book form Ken Schwaber - Agile project Management with Scrum:

TFS for Project Management

2009-06-22T18:31:00.002+10:00

Team Foundation Server (TFS) is a Microsoft offering for source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects.
It is available either as stand-alone software, or as the server side back end platform for Visual Studio Team System (VSTS).

TFS Architecture:

When creating a project, there are 2 project templates to choose from:

MSF Agile:

Provide Work items and Processes that support Agile programming approach

MSF CMMI

Based on MSF Agile, it stretches the Agile approach to comply with CMMI Maturity level 3.

It is 150% larger than MSF Agile, for example MSF Agile has 25 work product artefacts, MSF CMMI has 59.

TFS manages pretty much everything as Work Items:

The recommended links organisation is as follows:

Queries and reports can be developed in order to retreive any data from TFS. There are existing reports, such as Bugs rate and Remaining work.

SharePoint Web Access allows web access to all the information in TFS: Work items, Queires, Reports, Documents, Source Control, Builds and also Timesheets. SharePoint can be used by project Stakeholders, including the Customer if you wish.

SharePoint Project Portal provides documents repositories for projects and Wiki features.

The Integration of TFS and Excel allows to extract any data from TFS into Excel, using queries. The data is copied in the spreadsheet and can be refreshed from TFS at the press of a button. The data can also be edited in Excel and be published in TFS. Charts can then be developed in Excel.

It is also possible to develop pivot-table that access the TFS database directly (instead of running a TFS query).

There are also plug-ins to TFS, such as:

Calibre VSTS Add-in, which allows synchronisation of requirements with the tool from Borland
Test Director Synchronisation Engine, which allows synchronisation of bugs with the Quality Centre.

Also TFS Power Tools, to be downloaded, offer very interesting features, such as:

Process Template Editor
Work Item Editor
Custom check-in policies
TFS Server Manager
TFS Client Tool
Alert Editor

Finally TFS 2010 will offer the following additional features:

Architecture Explorer, which is a graphical visualisation of code
7 diagrams UML supported, for design and share diagrams
Tools for test cases management, such as tooling for better documentation & test
Test Impact View, which allows to run tests impacted by a code change only
Enhanced Vision Control, with gated check-in, branch visualisation & build workflow

Effective Thinking

2009-06-20T09:56:00.001+10:00

In order to think effectively, one needs to avoid rules of thumb and short-cuts.

Heuristics for effective thinking:

Availability heuristics: Recall most vivid memories
Representiveness heuristics: Judge something with something else it looks like
Anchoring heuristics: Judge something with its distance from the anchor

Thinking traps:

Selective perseption
Contrast effect
Rationalisation effect

Short cuts:

Cognitive laziness => Need to gather more information, concrete facts and figures, short-term and long-term consequences.

Biases and Assumptions:

Consistency bias => Examine your motives regarding the problem
Confirmation bias => List possible causes of past outcomes. Purposefully focus on contradictory evidence. Seek input from impartial 3rd party
Hindsight bias
Attribution biases (self-serving bias, egocentric bias or fundamental attribution error)

Problem Solving Mindsets:

Apathetic mindset
Adaptive mindset
Analitical mindset

Decision making styles:

Despote
Judge
Waffler
Safety blanket

Obtain a wide range of experiences and maintain a learning log.

Ellipse ERP in a nutshell

2009-06-19T16:02:00.001+10:00

In a nutshell, Ellipse ERP is organised as follows:

1- Maintenance:

Equipment Register (Core)
Work Orders (Core)
Standard Jobs
Equipment Group Identifier
Equipment Tracing / History
Projects
Maintenance Scheduling
Work Groups

2- Supply Chain (Requisition, Approval, Consolidation, Pick, Acquit Receipt):

Catalogue (Core)
Inventory Management (Core)
Suppliers (Core)
Purchasing (Core)
Warehouse Management
Forward Purchasing Agreements
Repairables
Inventory Tracking
Transport
Disposables
Entitlements

3- HR:

Personel
Payroll
Leave / Absence Management
Time and Attendance
Position Management
Recruitment
Training
Performance Management

4- Finance:

Journal Holding
Chart of Account
General Ledger
General Ledger Statistics
Journals
Management Accounting

5- Administration:

System Administration
Table files

Applications naming conventions:

MSO - Online Programs
MSB - Batches
MSR/A - Reports
MSS - Subroutines
MSQ - Smart client applications
MSE - Web Applications
MSF - Data Files

Staff Development

2009-06-17T15:36:00.001+10:00

When it comes to staff development, one wants to start by identifying the Leaders. Here are a number of theories that can help in identifying Leaders:

Trait theory: Charism, Intelligence, Confidence, Influence, Business knowledge
Equity theory: Efforts rewarded fairly
Behavioral theory: Combine reaching specific goals and building relationships
Contingency theory: How leaders adjust under different circunstances
Situational theory: Strong leaders adjust to the needs of employees

Transactional leadership sets expectations and reward system, and manages by exception.
Tranformational leadership builds relationships, leads by example, and endeavours to make positive changes.

Developing staff through Organisational Development:

Change management
Knowledge management
Learning organisations

Organisational Development Interventions:

Total Quality Management: Eliminating defects in processes.
Six Sigma: Client orientation and management focused methodology for improving quality.
High-involvement Organisations: Entrust employees at all levels as decision makers.

Human Process Interventions:

Leadership development
Team building
Conflict resolution
Emotional Intelligence

Human Resource Development Interventions:

Performance management
Diversity programs

Agile Map

2009-06-17T14:04:00.001+10:00

See this article http://www.taskmap.com/Agile%20-%20Overview.html, which presents an interesting map of the Agile processes.

IT Professional of 17 years

2009-06-17T09:08:00.005+10:00

I am an IT Professional of 17 years with specialisations of Project Management, Business Analysis, System Analysis and Software Engineering Methodologies – UML, RUP, Agile (MSF Agile, Scrum, XP and FDD) and CMMI. I hold a Project Manager Certification (Level 2) from the Australian Institute of Project Management (PMBoK).

I have worked for large, international and reputable companies in Australia and in Europe, within the following Business sectors:

Mining
ERP
Health
Telecommunications
Superannuation and Assurance
iTV
Utilities

Recently at Mincom, I contributed as a Project Manager to the development of 2 of their mining solutions, MineScape and MineMarket, undertaking C#.Net technology, and the redevelopment of the user interface of Mincom ERP Ellipse, undertaking J2EE technology. I lead up to 5 projects and 40 staff concurrently. I managed some outsourced developments off-shore, in India and Bali. I trained 40 staff with UML concepts, for Business Process Modelling, Requirements, Architecture and Design.

I have previously worked as a Software Architect for CSIRO E-Health Research Centre. I defined and documented the software architecture of the Health Data Integration (HDI) solution, using SOA, UML and RUP approaches, extracting and matching data from different databases for patients’ information analysis. Contributed to the developments, undertaking Java, web-services, XML and SQL.
I have also participated in the definition and development of an embedded software for a biological organism detection automaton and a laboratory support application, involving Molecular Biology, for BioMerieux.

I worked as Business Analyst and Software Architect for ‘Yes’ Optus, eliciting requirements, documenting business processes and defining system architecture, undertaking Business Process Management, BPMN, SOA, UML, Agile and Java technology.
I have also developed and tested a client-server middleware and transaction server for France Telecom – Telecommunication Company. I specialised in error management.

At WorkCover Qld, I have been awarded and recognised for delivering the intranet and content management system, surpassing schedule, cost and quality expectations. I managed relationships with internal Customer on the business side.
I was selected by a Superannuation Government Agency as a Consultant Project Manager RUP to perform a complete risk analysis on $10 million project behind schedule and with high-risk profile. Documented mitigation action plan. The plan was approved without alteration and I was subsequently selected to manage the project.

I worked as a Consultant Project Manager RUP, coaching Project Managers, Quality Assurance Managers, Architects and Business Analysts in implementing Software Development and Project Management methodologies; coaching people to tailor processes and undertake UML.

Working for Lysis in Digital TV and Interactive TV (iTV) environment, I lead 3 projects as Project Manager, undertaking Asset & Content Management and Task Scheduling. I managed a budget of about AU$2 million and met clients in Switzerland, Spain, Germany & Turkey, in order to determine project scope and write Statement of Work documents, which were validated by management and clients.
I also lead 3 projects as System Architect. Participated in workshops with the marketing department and account managers, in order to elicit user and system requirements. Participated in the specification and design of the 3-tier application. Produced business requirements, system architecture and system design documents. Undertook UML. Developed with Java/J2ee/C++, JBoss, Oracle DB, XML, Windows.

Another time, I specified, designed and developed a supply network driver for France Gas & Electricity Utilities Company.

I like to focus on team motivation and leadership by consent. I like accomplishments and recognition in environments where integrity prevail.

I remain at your disposal for further information.
Please contact me on 04 03 78 49 23, in order to arrange a meeting.
I look forward to hearing from you.

Jean-Philippe JACQUET (aka John)

Personnal Accountability

2009-06-16T15:19:00.001+10:00

"I'm holding you accountable for the outcome."

Lack of Personal Accountability may show through Negativity:

Emphasis on blame or deflecting fault
Complaining tone
Expression of frustration or fear
No real productive answer
No suggested action
Judgemental tone

Positivity, on the other hand, is usually partnered with Personal Accountability:

Emphasis on helping or solving the problem
Willingness to take positive action
No accusation
None-judgemental tone
Emphasis on being open-minded and taking responsibility

Choose your attitude. Play. Make their day. Be present. Be world class!

Business Analysis and Business Case

2009-06-16T09:52:00.000+10:00

Business Analysis:

Create and maintain the Business Architecture, using Business Process modelling
Conduct a feasibility study, implementing a prototype
Scope the new business opportunities
Prepare the Business Case
Conduct the initial risk assessment, taking into account business risks, financial risks and technical risks.
Prepare decision package

Business Case:

Justify the project
Identify and quatify the costs and benefits
Document risks and initial mitigation plan
Offer options and suggested solution

Empower and Motivate Employees

2009-06-15T10:43:00.013+10:00

Of all the areas of project Management, people have the greatest potential to shorten software schedules across a variaty of projects. In order to be highly successful, Project Managers want to foster a motivating and energizing culture within their teams.
Motivation can make or break projects. It is undoubtedly the single greatest influence on how well people perform. Research studies have demonstrated that motivated Developers can produce up to 10 times more than their unmotivated counterpart.
Many common management practices however are penny-wise and pound foolish, trading huge losses in morale for minor methodology improvements or dubious budget savings.
Although motivation is a soft factor, the knowledge of how to motivate Software Developers is not a total mystery.
For most people, motivation comes through empowerment, autonomy and trust. The major motivation inhibitor on the other hand is fear.

Providing the best environment to promote motivation:

Give interesting job and challenging work
Provide personal development and flexible policies
Eliminate fear
Make eye contact and smile
Take responsibility - don't pass the buck
Be honest, loyal and work hard
Get inside the other person frame of reference
Solicit suggestions and act on them
Expect people to succeed
Be teachable - commit to learning
Inspire - touch their heart
Handle every single transaction with each and every person, no matter who that person is, as if you will have to live with that person in a small room for the rest of your life

In his book "Rapid Development" Steve McConnel describes the following:

"Compared to their Managers, Developers are somewhat more motivated by possibility for growth, personal life, opportunity for technical supervision. Developers are much less motivated by responsibility, recognition and interpersonal relationships with subordinates."

Developers and Managers are motivated by different factors, and this may contribute to miscommunication.
In order to motivate a Developer, it is recommended to emphasize technical challenges, autonomy, the chance to learn and use new skills, and career planning.
Let Developers focus on what they like doing most: developing software. Provide opportunities to learn and expand skills. Avoid excessive pressure.
Allow Developers to experience meaning in their work, responsibility for the outcome of their work, and know the actual results of their work activities. Avoid interuptions and distractions. Respect the need for time off.
Developers grow tired of working for unappreciative companies and rewards are therefore important to long-term motivation. Giving certificates of appreciation for example has proved efficient.
Endeavour to catch people doing something right or great, and give them a sincere praise:

I noticed you did [something great] on [that date].
I appreciated it because [its effect].

Celebrate special events. Provide T-shirts or mugs personalised with the project's or team's name.

Proper execution of a performance review can significantly increase or decrease motivation. Take the time to prepare and make sure your performance reviews increase motivation.
Some performance management system are so complicated and bureaucratic however that the simplicity and ease of coaching has gotten lost. Coaching is a simple conversation and one can use the following structure:

Opening statement: "I want to talk to you about [general area of performance]."
Observation: I've observed [behavior]."
Impact: "The impact is [impact on the job]."
Request: "From now on, I'd like you to [improved behavior]."

Morale Killers:

Developers are sensitive to being manipulated by management. They want management to deal with them in a straightforward manner.
One of the quickest ways to drop the motivation to zero is to present Developers with an impossible deadline.
Lack of appreciation for efforts
Inappropriate involvement of technically inept management
Not involving Developers in decisions that affect them
Productivity barriers and road blocks
Low quality and short-cuts
Heavy handed motivation campaigns

Finally, competition can get people to stretch themselves beyond what they even thought possible, while having fun. Most people will go a long way to try to win a fair competition.
Encourage team spirit by organising competitions between teams (not individuals). Make sure every team gets to win at some point or another. Recognise the teams for their strength anyway.
Make sure these competitions are about work (no dress or photo competition), and they are about productivity and fun (not just fun and not just productivity).

Open Source Test Automation Suite

2009-06-12T16:08:00.001+10:00

Windmill is an up-and-coming software test automation suite, which allows to record and playback in IE, Safari, Opera, and Firefox.

It has a very active open source community. The 1.2 release will feature speed and multi-window test capability.

Windmill - http://www.getwindmill.com/

Coping with Difficult People

2009-06-09T09:55:00.005+10:00

Robert M. Bramson has identified several patterns of behavior exhibited by difficult people, in his book Coping with Difficult People.
These patterns of behavior are:

Hostile-Agressive : Pushy and uses intimidation. Arbitrary and arrogant.
Complainer : Gripe without offering a solution. Seldom takes action to rectify a situation.
Silent-and-Non-Responsive : Not very communicative. Relies on others to share their feelings and thoughts.
Super-Agreeable : Never commit themselves. Fear rejection.
Negativist : Are fatalists. Often nay sayers.
Know-It-All : Self-appointed experts. Condescending.
Indecisive : Delays making decisions. Fear of hurting or alienating someone.

Project Managers will improve their skills significantly by having a good understanding of Bramson's work, as he provides a good insight on dealing with several types of difficult people.
Failure to deal with difficult people at meetings, for example, may result in achieving nothing. It also creates atmospheres of negativism that last long after these sessions are dusted.

Get it from Fishpond.com.au:

Java and .Net Interoperability

2009-06-08T14:48:00.001+10:00

JNBridge delivers a message-oriented bridge between Java and .NET objects, undertaking a JMS client on the Java side and .NET remoting on the CLR side.
JNBridgePro provides a proxy system that handles garbage collection gracefully. It provides Java object implementations to .NET Remoting.

JNBridge - http://www.jnbridge.com/

Code Quality - Prevention vs Correction

2009-06-05T14:27:00.005+10:00

When it comes to quality in general and code quality in particular, I very much believe in prevention prior to correction.
When asked about code quality, people tend to offer corrective type solutions. Corrective type solutions are good and necessary, but they are more costly and are worth being minimised by implementing a number of preventive solutions up-stream. Example of preventive actions:

Ensure quality of requirements - implement a continous requirements development and recording
Ensure quality of architecture and design - implement methodologies for concept and documentation, such as UML and RUP
Ensure quality of staff - implement relevant and continuous training programs and recognition programs - manage pressure intelligently
Ensure quality of project processes - implement methodologies for project management and software engineering, such as PMBoK, CMMI, RUP and/or a recognised Agile approach.

I have worked for companies which spend a lot of time on the preventive side of things, and other which spend none whatsoever. Experience shows that when time is spent imlementing preventive solutions, the overall time of developing software is no significantly shorter nor longer...
The time normally spent fixing bugs at the end, is instead spent up-front insuring quality. But then dividends pay in the maintenance phase, where things get much easier. One case study demonstrated that 50% less staff were required in the first 5 years of maintaining a software solution re-engineered using proper design and UML approach.
In my point of view, the frequency of total re-engineering needed is also significantly decreased.

As a conclusion, in my experience people implementing Agile approaches often tend to dismiss or minimise the preventive activities in the name of agility, while this is not an Agile requirement and it is undesirable for high quality outcomes.

RUP - Software Component Architecture

2009-05-11T08:11:00.007+10:00

What is Architecture?

In computer science, Architecture is the nature and structure of a system that determines the way it operates.

What Architecture is not:

Architecture is not a Framework: While an architecture can take into account the use of a framework, the definition of a framework is not sufficient! A framework is just one component.

The Technical Architecture (or Model of Architecture) is the nature of the system. For instance, it could be:

Monolitic
Client Server
Distributed
N-tier

Paradigms can be integrated, such as:

Model-View-Controller
Software Components
Design patterns

A framework can be defined, as part of the technical architecture.

The business architecture defines the structure of the system.
It should outline the different parts of the system, their role and their relationships, as for instance:

What Does Component Architecture Mean for RUP?

Components are cohesive groups of code, in source or executable form, with well-defined interfaces and behaviours that provide strong encapsulation of their contents, and are therefore replaceable.
Architectures based around components tend to reduce the effective size and complexity of the solution, and so are more robust and resilient.
In the examples below, there is the same number of objects, but a different level of complexity:

Definition for Software Component

A Software Component is an independent portion of code that is accessed through a defined interface.
Software Components may be just imaginary, and can always be defined whatever the technology used!
Software Components may also be physical entities, such as a library (e.g. DLL) or a distributed component (e.g. EJB, CORBA, DCOM, Web Services, etc.)… but not necessarily… and it is not because EJB are used that it is a well-thought Software Component Architecture.
Physical Software Components may be reused, purchased and/or replaced.

Business components are those that implement the functionality specific to a business.
A “Computation Engine”, which provides specific computation services, is an example of a business component.
Business components are more difficult to reuse than technical components, due to their specific nature.

Technical components are those that implement generic functionality.
An example of a technical component is “Document Printing”.
Technical components can be designed in order to be reused. They can be part of a technical framework.

Why using Software Components?

They usually manage to reduce the complexity of a software, by identifying well defined interfaces and independent portions of code.
While it is rather inefficient to give Use Cases to develop to Programmers directly, it is much more effective to give components to implement. ==> Would you envisage to outsource the development of a use case? It is easy to outsource the development of a component, or to buy an existing one.
This approach eases and improves workload estimations, planning & task assignment.
To reuse components is an efficient way because they are already developed and tested.

Components can be developed in order to be reusable, especially the components that provide common solutions to a wide range of common problems.
These reusable components, which may be larger than just collections of utilities or class libraries, form the basis of reuse within an organization, increasing overall software productivity and quality.
Before promoting furious reusability however, ensure that great experience and knowledge has been acquired in the domain of software components.

Because they are well defined, Components can be refactored with less pain than in a not-so-well structured / organised Architecture.
The interface of the component may be mostly unchanged, while the implementation is entirely reviewed.
Even if the interface is changed, finding the impacted code will be easier than finding what is using the multiple classes and methods that compose the component.

In the beginning of Software Development, documentation and system integration were usually poorly undertook, the Architect was often asked to contribute to the development effort, and the Customer would get to perform most of the testing.

RUP recommends to implement “Use Case Packages” as components for requirements, in order to gather requirements by type of functionality.
Indeed this approach will ease the following analysis and design of the application with software components.

Identifying components may be performed this way:

Identify different modules, packages, subsystems and layers, e.g. Billing and Subscription modules.
Try to find common features, e.g. printing out.
Split modules, define interfaces and relationships with other modules.
Iterate and go deeper to find as many components as possible. Use top-down approach, from Graphical Interface towards Data, and bottom-up approach at the same time.
Then apply patterns such as Model-View-Controller.

The Components specification will provide a brief description of the components and their relationships.
The result is usually described with Composite Structure or Component Diagrams and accompanying text, providing a high-level description for each component.

The Components Analysis will provide a brief definition of each component, and a detailed definition of its interfaces and relationships.
At this stage, Components are black boxes.
The result is usually obtained and described with Sequence Diagrams and/or Collaboration Diagrams. Class Diagrams can be used to describe the interfaces.

The Components Design will provide the detailed description of what is inside each component / inside the box.
The result is usually obtained and described with Sequence Diagrams, Collaboration Diagrams, Class Diagrams, State Diagrams, etc.

The implementation of the components can now easily be performed by a Developer or a Team.
The team will be responsible for maintaining the design of the component and for unit testing the component.
The team might be the supplier and/or the customer for another component/team.

Components can be individually tested and gradually integrated to form the whole system.When performing unit tests of a component, moke components (giving fake answers) can be used to form the test-bench of the component to test.

Note also that Service Oriented Architectures (SOA) are necessarily based on Software Components Architectures. Components are then implemented as services (Web-services, CORBA, RMI, etc.), which provide the benefit of being loosely coupled.

Risk Analysis 101

2009-05-09T08:33:00.009+10:00

In my experience, Risk Analysis is primarily about communication. If the communication going around the project is not open and efficient, no risk analysis approach will save it.
On the other hand, if there is good communication going, a simple risk analysis methodology will do wonders.

The objective of a risk analysis is to identify, quantify and as much as possible mitigate the effects of events that have the potential to prevent a project from reaching its objectives. A risk analysis is not about identifying dysfunctions or people to blame.

The goals of a risk analysis is to:

give confidence to the Project Manager that all the contingencies have been considered
help working teams to focus on the key issues
mitigate the potiential impact of certain risks
help to prepare for the unexpected
improve the control over the development life-cycle and increase the capability to achieve the project objectives

A common method consists in brainstorming sessions, which allow to establish a list of risks. Each risk has an assignee, who will have the responsibility to help analysing the risk, usually the subject matter expert.
Let's remind ourselves now one fundamental principle of risk analysis: "No idea is too stupide to be mentionned". This is why small risks and very important risks will be listed side by side.
Then each risk is the object of a detailled analysis, which will allow to determine the value of a number of attributes. In particular, risks are classified by category.

The following categories may be considered for Software Development projects:

Requirements
Analysis and Design
Coding
Test
Deployment
Training and Documentation
Maintenance and Support
General

Each risk is also allocated a value for importance. The calculation of the importance is realised by using a Probability-Impact matrix. In the following example the matrix give more importance to the impact over the probability:

Probability \ Severity	Low	Medium	High
Low	1	3	5
Medium	2	6	8
High	4	7	9

Still in the context of the calculation of the importance, it is recommended to undertake a ponderation of the severities in relation to cost, quality and planning, in order to take into account the imperatives of the project.

A risk analysis will allow to highlight a number of solutions susceptible to mitigate the risks. Solutions will translate into actions. Some of these actions will need to be undertaken rapidely, in order to prevent the apparition of risks. They are preventive actions. Some will rely on the risk being triggered. They are curative actions.
Each action is allocated a value for importance too, which is calculated with the importance of risks it is mitigating.

Risks may later be managed using Risk Management Plan type document, or project traking type document, such as Status Assessment.

The source of information should also be documented, as context for the risk analysis. For example, list the brainstorming sessions that have happened and the attendees.

When documenting the results of the risk analysis, it is recommended to provide first the catalog of risks as a summary, sorted by importance. Then describe the risks in details by category.
The following attributes are to be documented for each risk:

Description - what it is about
Indicator - how do we find out
Impact (source part, impacted part, probability, impact severity on cost, quality and planning)
Possible solutions - refering to actions

The risk repartition may be documented using charts as for example:

Severity repartition for planning, quality and/or cost
Risks repartition by category (risks number and % importance)
Risks control repartition (risks per person, team, group and/or organisation)

Proposed actions are listed with a reference, a description, an undertaking mechanism and associated risks (which are mitigated by the action).

In conclusion, most of the proposed actions should be preventive and therefore undertaken as soon as possible, as a fundamental principle of risks analysis consists in anticipating problems. Indeed risk analysis is not supposed to provide solutions to existing problems, as it is considered to be late.
It is recommended to undertake a process analyse, as per the RUP methodology for example, in order to describe actions in details and to anchor them within a well known methodology.

Finally the risks analysis identifies New risks. The risks management consists in turning risks from New to Open when they are triggered, and turning them from Open to Closed when they have been treated.

Existing problems, at the time of the risks analysis, aren't identified as risks, since no probability can associated, but they may be managed as open risks during risk management.

Describe Business Processes with UML

2009-04-23T07:32:00.006+10:00

When describing requirements using UML, any attempt to order use cases or provide sequence information amongst use cases is bad practice, and can only lead to misuse of the UML use case diagrams.

One need to describe the Business Processes for the system under study, as this will provide the order in which things shall happen in much details.
Business Process can be documented in the Overview/Context section of a Product Requirements document.
OMG defines a BPMN notation to describe Business Processes (see http://www.bpmn.org/), which is basically based on a UML 2.0 activity diagram with a number of additional icons / features. This notation however doesn't add much other than confusion for the non-expert. I am indeed very much in favour of self-explanatory / unambiguous diagrams, as in my experience UML diagrams must be reviewed and approved by subject-matter-experts who usually are not UML experts. So, unless you have a very good reason for using BPMN, just use activity diagrams to describe Business Processes.
BPMN, while based on UML 2.0, is still in need for a consolidation with UML notations.

Otherwise, it is important not to undertake UML without a methodology. In order to be highly successful in documenting a system of any complexity, it is important to follow a formal methodology.
I personally like to use a methodology based on RUP, especially for the documentation of the requirements and the architecture, while agile approach principals can be used for the design and the development...

Calculate Earned Value with TFS

2009-04-04T19:16:00.036+10:00

Calculate the Earned Value of a project on a weekly basis, using TFS, MSProject and MSExcel.

In this article we'll explain how to calculate an Earned Value in days. It can be calculated in $ in a similar way... It is just a little more complicated.

It will work with TFS 2008, Office 2003 and Windows XP.

At the time of writing, it won't work with Office 2007 and Windows Vista.

1- Define the tasks in TFS

First, the tasks from the work-breakdown-structure are entered in TFS, and assigned to team members as required.

A query will be needed to list all the tasks for your project, including the closed ones, so tasks don't desappear as they get closed.

2- Use MSProject for the schedule

Though it is possible, it is unlikely that all the tasks of a project will be entered in TFS; typically Project Management or certain tasks performed by Consultants, for example.

Anyway, I like to have a semi-detailed schedule in MSProject, which will cover for all the tasks in the project. The tasks in TFS may be imported in MSProject automatically, using the TFS client tools, but I personally prefer to do this manually.

This is because I might have to prepare a project report as per Friday night on Friday afternoon, and TFS might not always be up-to-date. We have also experienced some problems with this interface.

I do however tend to group TFS tasks into a smaller number of tasks in MSProject, especially when there are hundreds or thousands of tasks, in order to make thinks easier. In this objective, the TFS tasks can be imported automatically in an MSExcel sheet (which works much better), using the query we mentioned earlier.

Then some calculations can be performed, in order to get Remaining time and %Complete values by group of tasks.

3- Export the schedule baseline into MSExcel

For the Earned Value chart, we need the Planned Effort values.

In this objective, we save the schedule baseline using the Resource Usage view in MSProject. Make sure that the values displayed go every 7 days (one week) and then copy and paste them in an MSExcel sheet, and replace the 'd' that comes with the numbers by nothing, so they are interpreted as numbers by MSExcel.

Now for each column, we need to add the week number, so it can be reference in the Earned Value table, in order to get the Planned Effort for each week. I personally like to use the format "2009w8" for the 8th week of 2009 for example.

We also need to calculate the sum of each column and the cumul of the sum for each column.

4- Get TFS Tasks updated

The Developers / Team menbers need to update the tasks that are assigned to them in TFS at least once a week. It is usually convenient to get them to do that at the same time they enter their timesheet. They need to update the Remaining Time and the status of the tasks they've been working on.

5- Update the schedule

The list of tasks in MSExcel can now be refreshed automatically with the latest values in TFS, and the schedule can be updated (manually), in order to reflect the progress on the project.

6- Update the Actuals from TFS Timesheet

In theory, TFS Timesheet can update the TFS Tasks Completed Time automatically, but at the time of writting we haven't been able to get this to work properly.

So in order to obtain the actuals, we've been able to setup a pivot-table in MSExcel; Setup an external Data-Source pointing to a view, which is refering to the tfstimesheet table in SQL Server on the TFS Server.

We just needed the Work Item Id on the left, the sum of hours from timesheet entries in the middle and nothing on top, in order to get only one column with hours. Then a SUMIF formula allowed us to update the Completed time in the tasks listed in a different MSExcel sheet and to publish these values back in TFS.

7- Update the Earned Value data from MSProject

The Estimate At Completion (or EAC) for the project will be provided by the value in the Work column in MSProject.

The Earned Value is calculated from the %Complete of the project multiplicated by the baseline budget (in days) or Total Budget in the figure below.

The Total Budget is saved every week, because it can change over time, as the project needs to be re-baselined when significant changes happen. In this case if the history of Total Budget was not saved the values of the Earned Value would be impacted.

8- Draw the Earned Value Chart

Unambiguous and understandable UML

2009-03-31T16:59:00.002+10:00

The original and fundamental phylosophy of UML is to be unambiguous and understable by most, without requiring an in-depth knowledge of a complex semantique.
This phylosophy had for objective to facilitate the communication in between the different stakeholders of Software Engineering projects and to federate the notations to promote common understanding and shared vision.
It is obvious to me that the original phylosophy is getting diluted progressively amongst the different additions that have been made to the standard over the years.

I do find myself very much in tune with this presentation umlbooch.ppt made by Grady Booch, and which promotes the need to address the increasing complexity of the systems to develop.
My personal vision is to try to keep UML unambiguous and understandable by most, in order to get as many people on board as possible and to address the problematic of the increasing complexity.

Project Take Over

2009-03-29T10:43:00.001+10:00

Taking over a new project, a new role or a new job... Restarting.

The objectives a project take over are (in this order):

Ensure long-term success of the Project Manager
Ensure success of the project

In order to take over a project successfully, the following steps shall be undertaken:

Establish authority and leadership with confidence
Establish relationships with every individual - learn about each one of them, what are their skills, experience, what type of management get the most of them, what are their motivators, personality and character.
Assess Project - take ownership of the project plan and the schedule, and assume resposibility from there on - if plan does seem achievable, perform the foolwing actions in this order: 1. try to reduce scope, 2. try technical simplifications, 3. justify and ask for more resources, and 4. propose to replan the project.
Assess and document Risks and Issues - perform a complete risk analysis, in order to confirm that the project objectives are achievable
Document Vision and Action Plan - based on well know methodology
Establish Project Management Master Mind

Spend a fair amount of your time improving your leadership ability:

Provide navigation
Establish solid ground
Influence
Process knowledge
Get momentum
Focus on victory
Establish inner cycle
Maintain priorities

Project Management Master-Mind

2009-03-23T06:20:00.003+10:00

The Master Mind principle consists in a group of capable and as much as possible complementary people, who cooperate in the spirit of harmony, in order to gain power.
Plans are useless without the power to translate them into action...

The idea behind a Project Management Master Mind is the organisation of a group of professionals dedicated to manage projects, a bit like an informal Project management Office.

A Project Management Master Mind aims at achieving the following objectives:

Managing projects to successful completion
Sharing knowledge and information - power is 'organised knowledge'
Sharing brainstorming power, decision power and responsibilities
Sharing a common vision
Providing coherent answers and solutions to project stakeholders - maximising credibility
Ability to keep functioning at near full strength, when one member is temporarily missing

The best source to create your Master Mind is within your team.
In your Project Management Master Mind it is recommended to include people with different backgrounds, experience and responsibilities, as for example:

Business – such as Business Analyst
Technical – Such as Technical Leader / Architect
Resource Management – Such as Manager

For the organisation of your Master Mind, you may also want to consider the following:

Master Mind members should be located close to each other as much as possible, in order to facilitate the communication as per the points below
They should keep each other informed first and systematically - so each member of the Master Mind is credible when standing on his own
They should meet often, with regular formal and informal meetings, such as when higher-management or customer is seeking information / answers or decisions need to be made
They should seek each other’s agreement for every significant decision - decision that are decided by a group in harmony are more sound and much more difficult to shoot down
They should assume full responsibility - The Project management Team is responsible for everything that is going on within the project!
They should support and be loyal to each other - discuss any issue or sensitive subject with the person face to face and nobody else, and give empathy

Maintaining a Shared Vision

2009-03-22T20:08:00.014+10:00

Creating a shared vision consists of establishing and actively maintaining agreement and commitment about what is to be done and how it will be done.
A shared vision is a result of an ongoing dialog among all the people working on the project.

The objectives of a shared vision are:
-Facilitating people working together.
-Helping people to attain unity of purpose.
-Creating a common understanding.

Attention: unrealistic proclamations can transform the shared vision into a source of frustration

Define the focus, for example:

The main focus is the success of the project and the customer satisfaction, all along the project life.

Define the Project Structure:

The project structure describes the caps (or roles) and relationships (or interfaces) for a software development project:
-Several caps may be put on one head.
-One cap may be worn by several heads.
-The represented relationships would describe the official communication stream (or process).

Obtain Assignment Acceptance:

People and activities assignments result from an agreement between Project Manager and Assigned person.
When no solution can be found, or for important responsibilities, the acceptance of higher-level management and/or other stakeholders will be required.

Other Areas to be considered:

Common Values
Team Empowerment and Independence
Decision Making
Conflict Resolution
Proposed Products and Tools
Constraints
Expectations

Processes & Methodologies

2009-03-16T20:26:00.003+10:00

What do you know about Processes?

Dictionary definition: Processes are operational systems for supplying or realising products. Processes may include separate stages with clearly defined end-points, which represent significant new or enhanced steps towards a final result.
Processes are usually integrated within a “more comprehensive” Methodology.
Methodologies could be and must be tailored, according to company’s and project’s objectives.

Does it ensure quality?
Yes… It helps ensuring products meet quality requirements, providing best practices to implement and standards to meet.

Does it make everybody’s life easier?
Yes… It helps reducing stress and frustrations, providing a frame for organisation, so people know what to expect and what is expected from them.

Does it save money?
Yes… It helps saving money, ensuring that the cost of adding new features and maintaining the product does not increase exponentially with time, which often force companies to redevelop their products from scratch after a while…

Conventional methodologies

The Capacity Maturity Model Integration (CMMI)
• developed by the US Department of Defence (DoD) in order to manage uncontrollable costs
• currently undertaken by Boeing or the NASA for example
• defines 24 different processes

The Rational Unified Process (RUP)
• developed by Rational, now merged with IBM
• very trendy in Europe
• defines 9 different processes

IT Infrastructure Library (ITIL)
• global methodology, not just software development
• developed by the UK Office of Government Commerce (OGC) in order to reduce costs
• defines a lot of different processes, packaged within 7 CDs

Project IN Controlled Environment (PRINCE2)
• project management method
• developed by the OGC
• defines 9 different processes

Agile Programming methodologies

eXtreme Programming (XP)
• developed by an individual, Kent Beck
• in use within Mercedes-Benz and Ford for example
• defines 7 practices (or processes)

Feature Driven Development (FDD)
• an Australian methodology
• trademark of the company Nebulon Pty Ltd
• in use within ‘Yes’ OPTUS telecommunication in Brisbane
• defines 5 processes

What are the main differences between Conventional and Agile Programming Methodologies?

Conventional methodologies
• requirements are unearthed at the start / elaboration phase
• models hold the design
• documentation is important

Agile programming methodologies
• requirements are unearthed again for each delivery
• code holds the design
• persons are important

What is it that all the methodologies are trying to eliminate?

Fire-fighting mode:
When some individuals, acting as heroes, are jumping from problem to problem, constantly saving the project from burning down completely.

Panic mode:
When the defined rules are not followed anymore, left aside, in order to rush forward (or to “fly by the seat of one’s pants”).

Conventional or Agile?

Up to recently, Conventional methods were considered the only option for large projects, while Agile ones were considered fast and practical for smaller projects.
Nowadays, Conventional methodologies claim to be more agile, and Agile ones claim to be able to manage larger projects…
Whatever the method, it must be tailored to meet project’s and company’s needs…

Are tools needed to implement a methodology?

NO… Not necessarily.
Tools can help, in certain situations, to increase productivity, however Processes are not about tools…
They are about people!