Blog posts from CASoft Pty Ltd | CASoft Blog

23 March 2009

Project Management Master-Mind

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

Share and Enjoy:

Comments (0)

22 March 2009

Maintaining a Shared Vision

Filed under: Project Management — Tags: Project Management — admin @ 21:08

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

Share and Enjoy:

Comments (0)

16 March 2009

Processes & Methodologies

Filed under: Methodology — Tags: Software Methodology — admin @ 21:26

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!

Share and Enjoy:

Comments (0)

11 March 2009

Hollywood Secrets of Project Management Success

Filed under: Book Review — Tags: Project Management — admin @ 21:29

Very good and entertaining book written by James R. Persse on Project Management best practices.

Get it from Fishpond.com.au:

18 Lessons are listed and thoughly documented, using examples from reknown Hollywood projects.
This book will convince you of the necessity to have in place a Project Management System and to follow it.

It will also encourage you to learn more on subjects such as Portfolio Management.

Share and Enjoy:

Comments (0)

9 March 2009

TFS – Federating Software Engineering

Filed under: Agile,Project Management — Tags: Project Management, Software Methodology — admin @ 19:58

Years ago in the manufacturing industry, ERP solutions federated all the information in one place, in order to optimise processes and costs.

The coming generation of tools for Software Engineering Project Management are on their way to doing just that. There is still a long way to go, but the trend is there.

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 one of the best tools out there today for managing and federating the information of Software Engineering projects and for Project Management.

When creating a project within TFS, there are 2 project templates to choose from:
–MSF Agile provides Work items and Processes that support Agile programming approach
–MSF CMMI is based on MSF Agile, and 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 artifacts, MSF CMMI has 59.

In TFS, everything in managed as a Work Item. The Work Items available, when using MSF Agile, are Scenario, Task, Bug, Risk and Quality of Service Requirement.
It is however possible and easy to add other work items, such as Test Case and Requirement.

In their presentations about TFS, Microsoft recommend the following links organisation:
Queries can be created to research Work Items.

Reports can be developed and run to provide all sorts of information and calculated measures about Work Items and projects, such as Bugs rate and Remaining work for example.

SharePoint Web Access is the Web Interface that provides access to all the TFS functionality through a web-based application. Timesheets can be entered using SharePoint Web Access.

Customers can be given access to the information about their projects through SharePoint Web Access, and can monitor their progress. This can decrease significantly the need for reporting.

The TFS solution also provides a Portal as a single point of storage for documents, which can be organised by project for example. It also has a wiki-like feature.

It possible to export the information in TFS into EXCEL spreadsheets, which can be updated / refreshed at the click of a button. This information can be instanciated in tables or in pivot-tables. It is also possible to modify the information in the spreadsheet and upload it back in TFS. Some teams choose to upload their requirements this way.

They are also add-ins that allow integration with third party products, such as Caliber and Test Director.

The Power Tools, which must be downloaded and installed separately, allow to create and edit processes and work items, and much more.

The 2010 edition of TFS will provide the following functionality:

Architecture Explorer provide a graphical visualisation of the code
7 UML diagrams will be supported (the Microsoft Diagrams won’t be supported, though Microsoft is working on their Oslo model-driven development strategy)
Tools for test cases management
Test Impact View – run tests impacted by a code change only
Enhanced Vision Control – gated check-in, branch visualisation and build worklfow

What do you like or dislike about TFS? leave comments below.

Share and Enjoy:

Comments (0)

Initiation to UML

Filed under: UML — Tags: Software Methodology, UML — admin @ 16:38

I organise several Initiation to UML courses, which include hands-on exercises, such as:

Requirements Analysis using UML
Software Architecture Analysis using UML
Software Design Analysis using UML

These 3 courses are usually intended for Software Developers, Architects and System Analysts, and form one entity that provides a coherent overview of UML and a methodology based on RUP.

A complete UML course will normally take 5 days, but I like to taylor the presentations and exercises to the client’s needs.

When people start learning UML, they want to know and usually focus on the syntax. I believe the philosophy and approach are far more important, and the syntax can readily be found on the Internet or in books.

Believing in UML and its capacity to improve communication, robutness and predictability in the Software Engineering industry, I am always keen to promote it.

I also provide coaching and mentoring.

I would be delighted to have a brainstorming session or chit-chat with you on the subject any time. Contact me at jjacquet@writeup.com.au.

Share and Enjoy:

Comments (0)

8 March 2009

Why UML?

Filed under: UML — Tags: Software Methodology, UML — admin @ 16:15

The Unified Modelling Language (UML) was published in 1995 as a merge of several older notations and approaches, including in particular OMT (Object Modelling Technique), Booch method and OOSE.

The objective of UML was to put together a common syntax, which would be simple enough to be readable by about anybody, while being unambiguous, along with methodology guidelines (which came in force years later with RUP).

The challenge in Software Engineering today is to describe a sometimes complex system in simple terms, without ambiguity and without omitting major concepts… So that everyone on a project has the same understanding, from the Junior Developer to the Project Manager and the Customer.

Why undertaking UML?
–The UML is an OMG standard,
–The UML has a wide acceptance in industry,
–There are a lot of tools which support the UML,
–Use of the UML is independent of software development processes,
–Object-oriented design has become very popular in software development projects,
–There also is a lot of textbooks about UML.

I give UML courses. Contact me at bne.lifestyle@optusnet.com.au.

Share and Enjoy:

Comments (0)

25 February 2009

Introduction to RUP

Filed under: RUP — Tags: RUP, Software Components, Software Methodology — admin @ 20:09

Are you a Pointy Hair Manager?

Think again… Look in a mirror.
You run the risk of finding a Dilbert cartoon taped on your door some day if you think that:
–Software development is primarily about programming,
–Managing a software project is no different to managing any other project,
–The best approach is to establish a detailed plan at the beginning and make sure everyone abides by it on a daily basis,
–A safe way to proceed with the product is to freeze all requirements early, in order to minimize any risk of schedule slippage and late surprises,
–etc.

The Rational Unified Process (RUP) is a Software Engineering Process.
–It provides a guide to help determine who does what, when and how.
–It can be mixed with other methods (e.g. quality insurance, CMMI, Agile…).

Why to apply RUP?
–Computer systems complexity.
–Reproducibility and Predictability.
–RUP gathers best practices that have proven themselves.

RUP, 3 Foundations:

–Use case driven,
–Architecture centred,
–Iterative and incremental.

RUP, Best Practices:

1.Iterative approach
2.Requirements management
3.Software component based architecture
4.Graphical modelisation of concepts
5.Permanent software quality checking
6.Change control

Maturity Level:

The Capacity Maturity Model Integration (CMMI) is process oriented and defines 5 levels of maturity:
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimising

RUP uses the process approach and allows an organisation to reach CMMI levels 2 or 3.

RUP Software development life cycle is organised into phases:

Iterative Approach:

Time Organisation:

Requirements Management:

–Discovering user requirements,
–Writing business use-cases with scenarios.
–Reorganising business use-cases into use-cases with attributes.
–Tracking requirements all along the development process.

Graphical Modelisation and Component Based Architecture are important subjects and will be the object of an article on their own.

Permanent Quality Checking:

ISO definition for quality:
–Quality is the property of what is conform to the requirements

Quality checking:
–Metrics assessment
–Defect tracking
–Code review
–Phase and iteration review
–Project tracking

Change Control:

–Change Request Management
–Configuration Management
–Measurement

Worker-Activity-Artifact diagrams are provided as guidance for the different processes of Software Engineering.

Organisation:

It is recommended to organise projects in smaller groups in order to facilitate communication.

Risk Management:
The adoption of an iterative approach allows the reduction of the risks earlier in the project life cycle.
Conclusion:

These are recommendations and guidances, which are to be tailored to your needs, to the size of the project and to the size of the company.

The Unified Process allows to improve the quality and control over Software Development Life Cycle (SDLC), in order to:
–reinforce capacity to reach defined goals,
–decrease the cost of the whole software development, especially maintenance.

RUP has also proved that it can be light and agile.
Useful Resources:
Mapping between RUP and PMBoK article: http://www.ibm.com/developerworks/rational/library/4721.html

Share and Enjoy:

Comments (0)

« Newer Posts — Older Posts »

Communication Aspects in Software Engineering

23 March 2009

22 March 2009

16 March 2009

11 March 2009

9 March 2009

8 March 2009

25 February 2009