ProjectPro.org.uk

This enterprise started back in late 2009, with the ambition to create and provide mobile applications (’apps’). The rationale being to focus on the needs of the user and provide apps which are as flexible and as simple as possible to use. The development process involves repeatedly ‘boiling-down’ to get to the heart of each feature implemented.

Fundamental to that process is Titanium from ‘Appcelerator‘  which aligns perfectly – enabling developers to build apps rapidly for multiple platforms from a single technology (in this instance Javascript).

In March, www.keepitsimpleapps.com deployed it’s ‘maiden’ app: AppNotes v1.0 for the iPhone, followed by an enhancement (v1.1) one month later. There’s another enhancement about to start which hopefully should be released in a week or two.

Aside from AppNotes, there’s a much more significant project in the works, details of which will hopefully be coming out in the next few weeks.

More from Southwest Airlines on Social Media (part 2 of 2).

I figured it was time for another video – more from Southwest Airlines on Social Media (part 1 of 2).

It may sound obvious to most but Project Management and Line Management are different roles and each brings specific skills, working together in an effective organisation.

Line managers have the ongoing responsibility for the admin, personal development, job satisfaction and well-being of those under their charge.

Project Managers focus is on achieving the objectives of a project. He/she has responsibilities the Line Manager may not (such as managing Risk, Scope, and the Customer).

The temporary nature of projects means that good quality line management is vital to ensure staff have the continuity and stability from which to contribute effectively to their projects. A company run by Project Managers would be a pretty scary place.

Like understanding your customer, the more you know your sponsor the easier it will be to have effective communications with them.

Work out how much information they require and if necessary have a conversation openly on when they want you to advise them, what they need in reports, how often, etc.

I would always push to lower the threshold a tad, as it’s better to have raised an issue that gets quickly resolved, than hold-back on a critical problem. After all the Sponsor is the ultimate stakeholder and should have the greatest to gain/lose from the outcome of the project.

For those that may not have ventured far into the site, it isn’t all quiet. I’ve been enhancing the Career History page  to showcase some of the sites I have project-managed in my current position (with the obligatory Lightbox effect).

I have added a summary of the project to provide and maintain a site for a local business (Ammi Flowers) that I was asked to put together. It’s been well received by the proprieter and their customers and is regularly revised and enhanced as the business develops.

Click here to find out more.

Understand where you are going before you leave.

Sounds simple enough. And yet despite all the theory and experience of decades of software development, it’s amazing how often projects are pursued in a ‘pioneering’ fashion.

An impatience to start build can be overwhelming, but projects routinely fail because insufficient thought and preparation is done before cutting code.

For the project team to work effectively, developers need to know where their work fits into the whole and also what business needs they are aiming to satisfy.

A failure to adequately comprehend and define how the solution will acheive the business objectives and ‘realise the benefits’ is a big risk and can easily mean the project will be late, blow the budget and leave an unhappy customer in it’s wake.

In terms of Project Control Processes, I’ve come to consider Risks and Issues as intrinsically linked, despite that many sources and courses teach these seperately.

Here’s the logic: An Issue is a Risk with a 100% likelyhood.

Issues are problems that need to be managed, in the same way as a risk once a trigger point has been reached.

The procedures for distinct risk registers and issue logs, means that Project managers can at best incur greater administration or at worst they can lose the holistic view that a combined view would give.

Ask yourself how many status meetings have you been to where the majority of the session is spent fire-fighting the issues and zipping through the risk log right at the end – or worst still, suggesting that be looked-at at the next meeting.

If the scoring system were adequately calculated it could be that some HUGE risks should merit higher attention than minor issues and should in truth be prioritised higher up any single list.

A browse of the shelves of a good bookstore and you’ll find quite a few books pronouncing the principles of project management. However, the literary style of many are given in the “Project Management made easy” mode.

Books which give the impression that Project Management need not be a constraint to the development process are misleading. Structure and control will always place constraints on what could be done in the fastest possible time. What the authors are trying to convey is that these constraints can be minimised, not that they can be jettisoned.

I strongly reccomend a site I found recently (http://www.projectsmart.co.uk/) which covers a good range of sensible material, and beats browsing “Project Management for dummies” or “The Ten-Minute Project Manager”-type media in your local bookshop.

Agile seems to be becoming the default approach to projects. However, here are a few of my own observations to those considering this methodology for their next project.

Agile was born out of a realisation that projects often delivered results that were obsolete or had little relevance to the business by go-live day. This was mostly because:

1. The requirements changed drastically from the start of the project; or
2. The business wasn’t able to describe the requirements at the start of the project.

Agile wasn’t designed to be the most economical approach and it inherently has features that mean it often costs more overall than waterfall.

The financial benefits of an Agile approach are attractive because of techniques associated with it (i.e. Prototyping, constant user interaction, prioritising requirements), but these are for the most part applicable to traditional waterfall projects as well. I would be interested to see metrics comparing waterfall versus agile where these specific techniques have been applied to both.

On the other hand Timeboxing, as a means of attaining flexibility, is a technique that sets Agile apart from the convential waterfall.

Sponsors and PMs should bear in mind that the core methodology is inherently inefficient, in that:

• Applying iterations means that code is revisited and may be modified several times (with multiple rounds of testing).
• Non-functional Protoypes are an overhead, if not used in the end solution.
• Greater user interaction means that customers must devote more time to the development process.
• And from a technical point-of-view code that has been rehashed several times can result in poorer performance.

But, on the assumption that a solution that is not ‘fit for purpose’ post implementation is a waste of time and money, what Agile was designed to offer is confidence.

• Confidence in timescales and budget – later iterations can potentially be dropped if either runs out.
• Confidence in suitability – that the solution will have undergone frequent review in the course of the project, rather than fixed from the start.

Back in the 1990’s DSDM (Dynamic Systems Development Methodology) included a suitability test, to establish whether the project was a credible candidate for it. From what I have read XP and “Scrum” don’t have this step. So the Project Manager must perform this assessment outside of the methodology, and I suspect that many projects are managed in an Agile way, without due consideration of whether it’s the right tool for the job.

So, rather than follow the herd, take a moment; weigh it up and conduct your next project in the most appropriate way. Don’t simply assume that Agile is always best.