As a business owner, you want to be spending your time servicing your customers and giving them the best possible experience. Providing them with the best value for money is a priority. You want to ensure your business can sustain the many challenges it faces. Growing your business is a key focus. You want to make sure you can finish each day feeling you have completed everything you planned to do that day and not having to worry about unfinished business after hours.

But does it work out that way?

Are you on top of your office and admin work? Do you sometimes find that the back-office functions get in the way of you spending time doing what you enjoy most about your work? Are you able to spend the right amount of time coaching your staff, keeping up to date with the fast-moving world of technology and improving your business processes?

Do you sometimes wish that you could spend more time with your customers and less time solving tedious invoicing, purchasing and accounting problems?

If running your business using spreadsheets and a variety of disconnected systems is eroding your time, there is a way to turn things around quickly.

That way is Striven.

Striven is a state of the art, all-in-one, business management solution which keeps everything in one place. It stores all your records relating to customers, suppliers, customer jobs, inventory, staff, invoices, bills, financial transactions, income, expenses and more.

Striven does away with the need for multiple disconnected systems that require duplicated data entry and constant attention switching. Striven acts as the single point of truth for all your data, removing the need for time wasting double checking and reconciliation.

Striven can be accessed on your mobile phone making it possible to see what is going on in your business when you are out and about.

Striven is inexpensive, costing less than $30/month per user for many small businesses.

If Striven sounds of interest to you, please provide your enquiry details via the Contact page.

We also offer a range of other IT project management services.

Please continue to browse this page to find other posts designed to help with IT project management.

To explain an IT project we need to explain IT and Project.

IT is Information Technology. Information Technology is technology that generates, stores, transfers, copies, modifies or protects data in some way.

IT can take the form of hardware or software. It can involve web applications, mobile applications, software programs, networks, data centres, storage, memory, cyber security, ecommerce, cloud solutions, operating systems, servers, internet of things (IoT) and operational technology.

Smart Start Consulting specialises in IT as opposed to other organisations that might focus on technologies centred on construction, science, humanitarian aid, natural environments, engineering, transport, armed forces, aerospace or other fields.

A Project is any activity that has a beginning and an end as opposed to a continuous activity. A project is usually a one-off undertaking established to meet a specific need or set of objectives. Example are the setting up of a accounting system or a payroll system.

One of the more common examples of a continuous activity is manufacturing where the same products might be produced year round. Other examples though would be the day to day running of a business including order taking, sales, marketing, finance, inventory management, procurement, legal and safety.

Smart Start Consulting recognises that an IT project is an activity that a small or medium sized business might need or choose to do only infrequently, or perhaps only once. The implication of this is that the business might not have sufficient in house personnel to deliver the IT project in addition to conducting all of the other business functions. It might also not have the expertise required to organise the project. In addition, it might not have sufficient financial resources to engage an external company to manage the project from beginning to end.

Smart Start Consulting can provide the expertise needed to allow the business to run the project themselves without needing to employ a whole project team.

Please continue to browse this page to find other posts designed to help with IT project management.

When a business builds a website, it will do so with the future in mind. It will be built for the immediate needs but it will also have the capacity to cater for the growth of the business.

As the business continues to benefit from the website, the business ownership and management will periodically re-evaluate the value provided by the website, its cost, its search engine optimisation, its speed, its aesthetic appeal and its accessibility, amongst other things.

At the same time, the business could change ownership, its products and services could grow or its strategic direction could change and these could trigger the need to change the website in some way. This could result in a website migration.

Website migration can include changes to any of the following:

1.       Website build software

2.       URL (Protocol, Subdomain, Domain name, Top Level Domain)

3.       Hosting provider

4.       Content

5.       Design and layout

6.       Theme

7.       Interface

8.       User experience

9.       Support

The changes can have an impact on usability, interoperability and ability to be found by search engines. In addition to the new website being up, it needs to be found as well.

Aspects that need to receive focus when undertaking a website migration are:

1.     Thorough evaluation of the pros and cons of the change

2.     Thorough planning of the change

3.     Continuity of website availability

4.     Continuity of integrated processes

5.     Removing confusion from the customer’s perspective

6.     Customers understanding that they have found the correct website

7.     No persistence of the old website

8.     Continuity of external support

9.     Ability to be found by search engines

10.   Maintenance of, or improvement in, search engine ranking

11.   Existence of a Business Continuity Plan in the event that the migration fails

12.   Website maintenance staff are involved in the project and trained in the new solution

13.   301 redirects are managed

14.   Redirect mappings are managed

A website migration is like any other IT project. It will benefit from advice from an experienced project manager.

Please continue to browse this page to find other posts designed to help with IT project management.

Your business might not have experienced corruption of data caused by a virus, damage to servers due to a burst water pipe, inability to access vendor support after a disk failure or more widespread disruption due to a building collapse or fire, but disasters can happen and it is important to be prepared.

Regulated industries, such as banking, require member organisations to protect themselves against disasters affecting their IT platforms by requiring them to duplicate their primary infrastructure in a secondary physical location. In addition to this, member organisations are required to perform annual tests of their disaster recovery infrastructure and processes by powering up their duplicated equipment and running tests to confirm everything is in good working order.

These requirements are conditions of their operating licenses.

Duplication of IT infrastructure can be prohibitively expensive, however loss of revenue due to an inability to trade can be completely overwhelming.

A cost-benefit analysis needs to be conducted which weighs up each of these costs and determines whether duplicated infrastructure is warranted or whether adequate protection can be provided with the use of backups, locating business software in the cloud (where disaster recovery is the responsibility of the cloud provider), provision of redundant hardware at the primary site or a fix-on-fail approach which essentially looks to repair damaged equipment in the event of a significant failure or compromise.

Closely associated with, and equally important as, the disaster recovery infrastructure is the preparation and availability of a business continuity plan. The plan outlines what will happen if the IT is unavailable. The measures outlined in the plan can vary from continuing operating using spreadsheets, using pen and paper, interrupting business transactions while repairs are made or engaging a third party to provide support.

The time to be thinking about disaster recovery and business continuity planning isn’t when a mission critical application suddenly ceases to operate and can’t be restored in a short space of time.

It is far better to proactively assess the consequences of IT failure and IT unavailability and implement a cost effective approach that can be supported by your business.

Please continue to browse this page to find other posts designed to help with IT project management.

Run sheets are used to describe the steps that need to be followed to release the change into production. That is, to put the solution live.

They outline the start and end times of each activity, the team members required to execute each activity, the description of each activity, the sequence in which the activities need to be performed and any times when team members are required to dial into the central phone bridge to receive instructions or to report back on the outcome of their activities.

The set of activities includes the establishment of a baseline where the state of the environment is checked before the change starts, the execution of the steps necessary to put the change into production and the testing that is required to ensure that the change has gone in successfully.

At various points during the change process, the project manager, with input from the subject matter experts, determines whether the change is on track or whether the change needs to be rolled back due to the number of difficulties that have been encountered. Unexpected challenges experienced during the change translate into activities taking longer than expected.

Consideration of a rollback needs to bear in mind the time it will take to roll back the change and it also needs to take into account the stated end time of the change window. A change that extends past the end time of the change is classified as a failed change. Also important to consider is the fact that if the change has experienced difficulty then the rollback might also experience difficulty and might take longer than expected.

Run sheet timings are based on how long it took to execute the same tasks in the Test/Quality Assurance (QA) environment. The QA environment isn't a mirror of the production environment so there is always a risk that the activities and durations in production could be slightly different from those observed in the QA environment.

When constructing a run sheet, it is important to introduce contingency (time) to act as a buffer in case unhelpful discoveries are made during the change or if planned activities take longer than expected.

Contingency is best inserted at the end of each phase of the change rather than as a lump sum at the end of the change. This allows an early assessment to be made as to whether the change will complete on time because each component of contingency is dedicated to each phase of the change and is not shared. If a phase of the change over runs its component of contingency then if all other phases of the change consume their contingency then the change will exceed its overall time allotment and will finish late.

When preparing run sheets, protect the change by allocating contingency to each phase of the change.

Please continue to browse this page to find other posts designed to help with IT project management.

Very large organisations, which have implemented complex and business-wide IT projects many times before, have in-house project management and project delivery personnel available to set up and run the next series of projects. They have already developed and implemented repeatable project management and delivery processes and have robust processes for preparing the business users for new solutions and for transitioning IT changes into the Production environment.

Although these organisations are large enough to be able to support the engagement of external consultants for project delivery advice, their experience removes the need for them to do this. 

Much smaller organisations, on the other hand, are unlikely to have delivered many or any large IT projects before and are unlikely to have in-house personnel who could be assigned to the management and delivery of IT projects. They also potentially don’t have a management team with the experience to be able to initiate an IT project.

These organisations are possibly not able to justify the engagement of external consultants for project delivery advice and, instead, make the decision to set up and run the project on their own.

The Smart Start Consulting market is in the middle. Clients of Smart Start Consulting will be those organisations that are small enough to require the assistance of an experienced adviser and large enough to be able to support the provision of cost-conscious advice and input from a seasoned IT project practitioner. Short term engagement is the primary service offering.

Contact Smart Start Consulting to start your project right!

Please continue to browse this page to find other posts designed to help with IT project management. 

You have made the decision to embark on a key IT project and you have the support of your Board. The project will deliver a solution that will facilitate increased revenue and market expansion.

You have worked in organisations where large projects of this type have been implemented, however this is the first time you are launching such a project as the business owner. It is the first time where you will be fully accountable for the smooth running and successful delivery of the project.

Your previous experience has taught you that IT projects can be costly and can face many challenges. You can see many ways in which the project could be delivered but aren’t sure how to decide on the best way forward.

Do you outsource the Project Management and delivery of the project to the company which currently supports your BAU IT operations? Do you outsource the delivery to the vendor of the solution you are implementing? Do you recruit a Project Manager and other key project personnel to deliver the project? Do you identify talented individuals from within your organisation and have them deliver the project? Are there other options available or is a hybrid of some of the above approaches the best way to go?

Once you have made a decision on the project management and delivery model, how will you juggle your core business/customer facing demands and your project demands?

If you need advice and guidance on how to set up the project, then a short term engagement with an experienced adviser will be very beneficial. This will help to contain the financial outlay and it can provide adequate time to apply the advice. In this way, you will not be pressured into delivering the project while the project team and governance frameworks are still being established.

Once the project delivery model has been established, there is an opportunity to set up another short term advisory engagement to focus on the lower level details. These are the project scope, schedule, cost, resourcing and business readiness.

In this way, big up-front commitments can be avoided and the way forward can be adjusted as more light is shed on key aspects of the project.

Contact Smart Start Consulting to start your project right!

Please continue to browse this page to find other posts designed to help with IT project management.

The Agile approach to project delivery has been around for two decades with the Manifesto for Agile Software Development dating back to 2001.

Agile was originally developed to manage the fixing of bugs in code and, in more recent times, its use has expanded dramatically to almost all project related activity, within and outside IT. Its use has also travelled outside projects.

Agile is particularly suited to situations where the near term objectives are known, but the longer term ones are not, as the Agile approach is flexible and allows for changes in direction at short notice.

Other key concepts of Agile are the ideas of iterative design and breaking work into smaller pieces.

One area that can benefit from the Agile approach is contract document preparation. Contracts can take a long time to develop and they can become the source of delivery delay. If an Agile approach is used to draft contracts then the contract can be sized in proportion to the work being delivered.

This means that the contract can start skinny and suit the simple product or service that is produced initially and then, as the product or service develops into something bigger, so too can the size and the complexity of the contract document.

The benefit of this is that the contract for the initial release can be prepared quickly and preparation of the more complex versions of the contract can occur in parallel with the development of the more complex products and can keep off the project’s critical path.

Another way the preparation of contractual documents can be accelerated is for the initial delivery (Minimum Viable Product) to be established via a Time and Materials arrangement where the contractual document doesn't need to tie down the scope to the last detail and the remainder of the project can be established via a Fixed Price arrangement which, through necessity, has much more content devoted to minute details regarding scope, timeline and cost.

Contact Smart Start Consulting to start your project right!

Please continue to browse this page to find other posts designed to help with IT project management.

The short answer is lots but, with the right guidance, you can keep your project on track to reach a rewarding conclusion.

If it's not kept on track, the project will cost more than expected, take longer to complete than desired and not deliver the anticipated value.

In theory, almost anything imaginable can go wrong with a project however, in reality, the pitfalls can be grouped into seven categories, namely:

• Formulation

• Commitment

• Oversight

• Capability

• Timeliness

• Readiness

• Support

Formulation

This covers the What, the Why and the How. What problem are we trying to solve, why are we attempting to solve it and how are we aiming to solve it?

The What: If the project sounds exciting but doesn’t deliver water-tight benefits, then the project will be questioned. If there isn’t a compelling case for doing the project then, sooner or later, it will experience challenges from higher priority projects or more urgent business imperatives. This will lead to it being de-prioritised, it will have its funding pulled, have its scope reduced and ultimately it will become a white elephant and a burden to the organisation.

IT projects are expensive and time consuming, so it is always critical to thoroughly investigate the ‘no technology’ option as well. Look at ways to solve the problem through business process change as well as through technology.

The Why: Is the project discretionary or non-discretionary? Do we have a choice in doing the project or not? Are there legal, regulatory or compliance obligations to deliver the project, or is the project driven by the organisation? If the project is driven by the organisation, what competitive advantage does it deliver? These questions need to be answered to ensure that we really do need to do the project. 

The How: Is there a prescriptive approach that must be followed, or is there a choice in how the project is delivered? Will the project employ Agile techniques, or is a traditional Waterfall approach best? Will the project be delivered using in-house personnel, or will the delivery be outsourced to an experienced third party? If a third party is used, will it be the software vendor or will it be an independent entity?

With the right guidance, these questions can be answered and the project can get off to the right start.

Commitment

Once the decision has been made to proceed with the project, then that's when the delivery journey begins. This will require concerted and sustained effort and will need the parties involved to be resilient and resourceful.

These qualities need to be displayed first and foremost by the project Sponsor, the Steering Committee and by Project Management. Team morale and enthusiasm for the project will be best maintained if the team can see that their leaders are engaged and committed to the initiative. If the team get the sense that the leadership have become distracted, or have lost motivation, then this will flow down to the team who will cease delivering optimally.

Aside from the impact to the team, it is also vital that the leadership remain committed, as the project will require all of their available capacity. If other demands intrude, then their influence and control over the project will diminish, delays will be introduced, things will begin to fall between the cracks and mistakes will be made.

In smaller organisations especially, where projects are delivered by small teams and by teams whose members have ‘day jobs’, it is easy to lose track of the status of activities and for momentum to be lost. It is critical that focus is maintained and that the delivery continues to be taken seriously. Conviction in the benefits being delivered is key and relentless pursuit of the desired outcome is paramount.

Oversight

As capable as the project team are likely to be, the project team doesn’t have the higher level perspective of the organisation that management and other senior stakeholders have. For the project to be successful, the organisation’s leadership needs to be constantly understanding what is being done on the project, its status and challenges and leadership need to be guiding the project so that it negotiates obstacles.

The leadership also needs to be guiding the project in the context of other initiatives and events that are occurring elsewhere in the organisation. No organisation stays still, and the landscape outside the organisation even less so. Those overseeing the project need to ensure the project is adjusting and correcting its course to see it remains relevant and continues to deliver value for the organisation.

The governance team need to understand their roles and need to be given support from their management so that they are effective in their roles and to do their roles justice.

Capability

Project funding is always under pressure and there is a natural tendency to think that things will be easier than they eventually turn out to be.

One of the casualties of this combination of factors is resourcing. Project team numbers are kept low to reduce cost and team members are loaded with work, including tasks beyond their skill set. The result is a project team that lacks all of the required capabilities, and this leads to sub-optimal delivery.

If new and unfamiliar technologies are involved, a lack of understanding of the technology can lead to omission of critical skill sets from the project team. If a team member is required to perform tasks beyond their abilities, they might try to do their best and not call out that they are out of their depth. Nobody likes to admit that they aren’t up to the task.

Industry-wide skill shortages due to an abundance of work will lead to a project needing to settle for a team that is not strong in all areas. This will lead to delays while the team come to terms with their assigned work and will lead to mistakes when challenges are not brought to the attention of the project leadership.

The attempt to cut costs also includes the Project Manager. Either no Project Manager is assigned, or a Project Manager is assigned who is not dedicated to the project and has other demands on their time. It is possible to manage the project without a Project Manager but real care needs to be taken.

Understanding these pitfalls, and accessing skilled advice and guidance, can ensure your project isn’t left short in the skills department.  

Timeliness

Starting late is a sure fire way to finish late. The old adages, Don’t put off until tomorrow that which you can do today and There is no time like the present are particularly relevant when it comes to managing projects.

Project value will be eroded if the end date is missed, so it is vital that momentum is maintained. You need to stay ahead just to keep up!

Before you can start thinking about timely completion of tasks, you need to understand when the tasks are planned to be completed. This means you need to have a schedule or a plan that outlines who is doing what, and by when. Clarity or roles and responsibilities and clear communication to the team about what needs to happen, and when, are the building blocks of on-time delivery.

It is tempting, at the beginning of a long project, to take it easy on the basis that there is plenty of time to catch up. It is also easy to justify moving cautiously by saying that all projects need a solid foundation. This isn’t a good overriding mindset to have however because once the project gets going there will be more than enough work to do without needing to attend to tasks that were due to be completed a long time ago.

Discovering that other team members had been taking their time at the beginning of the project will breed resentment as well.

It is hard enough to get the planned work done on time let alone do anything that has crept into the project scope. Tight control of changes is also key to timely delivery. Additions to scope need to be treated with suspicion and approved to be included in the project scope only after thorough evaluation of their benefits. It is often better to defer these scope additions to a later phase of the project to allow momentum and focus to be maintained.

Close monitoring of project progress is essential if adherence to the schedule is to persist. The introduction of milestones into the schedule allows delays to be discovered early and managed before a key date is missed by which time it is too late.

Taking extra time and care to plan the project at the outset will make a huge difference in the long run. Engaging an experienced advisor early on will give you the ability to start your project on time, and continue to track to your schedule.

Readiness

The soft stuff is the hard stuff it is said, and it's true.

In many ways, the implementation of a technical solution is easy. Code is predictable and doesn’t behave in inconsistent ways. It can be complex, but it is stable.

The user community in the business, on the other hand, have their own responsibilities and priorities and your project, as important as it is, might be only one of many things on their plate. Business As Usual challenges can be small or large. If your project end date is a long way off then the business might not start thinking about your project for a very long time, if at all!

This is why it is so important to engage the business early, to explain to them what you are doing for them, to explain how it will benefit them and to keep them informed of project progress throughout the project life cycle.

Equally important is the need to understand the impact of the project on the business and to identify any changes that the project, or you, might need to make to ensure there is a smooth transition from the current to the future state. This can include business process change, change to the organisational structure, including recruitment and training. The implementation tasks during cutover are also critical to the project's success.

Making sure that you have catered for the needs of the business in your design is vital. If they are to adopt your solution enthusiastically, then they need to be convinced that their future situation will be the same as, or better than, it is today. The moment the business get the sense that their lives are going to be made more difficult as a result of the project deliverables, understandably they will be very upset and will react badly.

Having someone guide you in the area of change management, training and communications will greatly improve the chances of your audience being advocates for your cause as opposed to detractors.

Support

Ultimately, the most important people in the whole picture are the customers of the solution that has been delivered. It is their needs that have given rise to the project and for the project to be seen as a success in their eyes, the solution needs to demonstrate value when the customers commence using it, and ongoing, for the life of the solution.

To ensure this value is maintained, it is critical that the solution be supported continuously once delivered. To achieve this outcome, many things need to be done. A support model needs to be developed, a support organisation needs to be identified and trained. This needs to be done in the early stages of the project because members of the support organisation need to come to terms with the solution before it is delivered and they are required to support it. To ensure this, the support organisation needs to be consulted and involved during the development of the solution. The support organisation needs to have the capacity and knowledge needed to allow them to service customer enquiries, in an effective way, from day one.

Knowledge requires training and this means that the project team needs to have the capacity to train the support team. Training needs to be provided to those who will be interacting directly with users as well as to the system support staff who will be maintaining the solution software in the form of upgrades, patch application and in the configuration of the application.

All of these support related activities need to be included in the project schedule, the project budget and the project resourcing.

With the right preparation early on in the project life cycle, strong buy-in from the support team can be achieved and the reputation of the project and the solution can soar.

Please continue to browse this page to find other posts designed to help with IT project management.

Yes, you can run a project without a Project Manager, but you will need help.

If you are a business owner and you need to deliver an IT project, you might consider running it without a Project Manager. Scenarios where this would make sense are:

• You are Tech savvy and have bandwidth to run the project yourself

• You don’t currently employ a Project Manager and don’t have sufficient funding to do so

• You want to upskill a staff member with Project Management aspirations

• You have engaged a Project Manager in the past and have learned from them

All of these are understandable and valid reasons to consider running your IT project without engaging a Project Manager. Your project can still be delivered successfully, however there will be a number of pitfalls to avoid.

Without training to be a Project Manager yourself, it is possible for you to run the project with experienced and targeted guidance.

At the very outset you will need to convince yourself, and your Board, that the project needs to be done. All too often a project is kicked off without a thorough investigation into the problem being solved and the benefits the project needs to deliver. The choice of solution is also critical.

Once the bullet-proof business case has been signed off, there is a need to delve into the project scope, and cost, in more detail. The project schedule needs to be prepared and the resourcing (people, equipment and facilities) needs to be understood. The project management and project delivery methodologies need to be decided upon and a full assessment of the delivery and delivered risks, as well as any existing issues, needs to be conducted.

The quality standard to which the project is to be delivered also needs to be confirmed. The reliance on vendors and outsource partners needs to be understood and contracts with these entities need to be negotiated.

The ability and readiness of the organisation to adopt the change being implemented needs to be assessed and managed and all stakeholders need to be kept informed of project progress and achievements.

None of this is rocket science and, as the old adage goes, it is easy when you know how. Guidance from an experienced practitioner can make all the difference.

The challenge with IT projects and their management, especially in small and medium sized enterprises, is that they are implemented infrequently. This means that the knowledge associated with the most recent project is not retained due to the inability to practice what was leaned on another project or because of staff turnover.

With professional assistance in the early formative stages of the project, a plan for the success of the project can be developed and, with periodic monitoring and review, the project can be kept on track to a rewarding conclusion.

Contact Smart Start Consulting to start your project right!

Please continue to browse this page to find other posts designed to help with IT project management.

When speed to market is a priority and when the external commercial, technical and regulatory environments are prone to frequent change, incremental delivery helps to reduce risk. Agile is well suited to, and well supports, incremental delivery.

The first iteration of a product can be sold to a segment of the market and the feedback from those sales can be used to evolve subsequent iterations of the product. The next round of sales will expose the more mature product to the same market segment or to a different market segment or more market segments.

As this is happening, the market could already be enjoying an earlier release of the product.

From a production support/after-sales service perspective, how will the existing and new products each be supported?

Will all support staff be trained in the first iteration of the new product or will a subset of people be trained? Will the existing call routing be appropriate or will it need to be modified?

These questions need to be answered otherwise a customer of the new product could be routed to a support team member who has not been trained in the new product.

Training the entire support team on a single iteration of a product which will be changing in the near future could be costly and, in some cases, a waste of time if call volumes are low or even non-existent.

On the other hand, a challenge could emerge if call volumes are higher than expected and if too few team members have been trained.

A useful solution to this dilemma is to adopt a multi-pronged approach. This involves:

• Training a small group of team members in the first iteration of the new product

• Providing all team members with an overview of the new product and issuing updates as the product evolves

• Updating the call routing system to introduce an option relating to the new product

• Using what has been learned from the release of the first iteration to inform the approach for upcoming iterations. This could result in the same group being trained in the second iteration, or broadening this group, depending on team skill set and call volumes

Using this approach can ensure that customers get the support they need without being excessively expensive for the organisation. Keeping the trained group small ensures calls help to maintain and reinforce their knowledge of the product. This will avoid a scenario where a person is trained and doesn’t receive calls and quickly forgets what they were taught.

Please continue to browse this page to find other posts designed to help with IT project management.

From time to time I hear Project Managers, and their managers, criticising Agile. Those being critical are sometimes those who haven’t ever used Agile on a project. They say Agile leads to a project’s scope being unbounded, requirements not being recorded, there being no schedule, the finances not being managed and status not being reported.

As a reminder, the Agile Manifesto promotes:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Some of the key observable ingredients of Agile are:

• Appointment of a Scrum Master

• Active input from a Product Manager

• Kanban boards

• Daily Stand Up meetings

• Breaking large scope elements into smaller pieces (Epics, Features and User Stories)

• Minimum Viable Product

• Failing fast

• User Stories and estimation

• Backlogs and backlog prioritisation

• Sprints

• Management of Work In Process

• Showcases

• Retrospectives

The purpose of the elements of the Agile framework is to manage the delivery activities. User Stories are assigned to Sprints and Daily Stand Ups are used to bring the team members together to discuss:

• What was achieved yesterday

• What is planned for today

• The blockers that exist

This approach lends itself to innovation initiatives where new ground is being broken, where prototypes need to be developed, where incremental delivery is beneficial, where a tried and tested delivery process is not known and where the external environment is changing frequently. Agile projects adopt a ‘fail fast’ approach where the team will ‘pivot’ if the current path hits a dead-end.

None of this precludes the use of familiar Project Management artefacts such as:

• Solution Architecture Documents

• Business Requirements Documents

• Commercial Contracts

• Project Schedules

• Project Budgets

• Finance Trackers

• Risk and Issue Registers

• Status Reports

In fact, these are not only permitted under Agile, they are compatible with Agile and essential for the support of the project overall.

Agile supports clear and simple communication, visualisation of progress and the ability to change course to enhance delivery velocity.

These elements are of value on any project, whether Agile or Waterfall.

Please continue to browse this page to find other posts designed to help with IT project management.

In recent times there has been an explosion of project management software available for free or purchase. Together with this hive of activity has come an expectation that projects will be managed using a software tool.

But what is project management software? What springs to mind when project management software is mentioned?

One immediate answer is Gantt chart software used to produce project schedules. These are sophisticated packages that record tasks and their sequence and inter-dependencies, include durations, assign resources, assign daily rates, calculate project costs and manage resource capacity. These are all essential elements of project management but this doesn’t cover everything a project needs.

Another answer is software that creates Kanban boards. There is a plethora of these available on the market. They facilitate Agile principles of User Stories, Backlogs and Work In Process and assist in the visualisation of tasks, assignment of responsibilities, management of progress and maintenance of delivery momentum. All of these are critical to the effective delivery of the project however don’t tell the whole story.

In addition to the above, available also are sophisticated, enterprise level, industrial strength software packages that manage a number of the above elements and are linked to the organisation’s core business systems.

The size of the organisation, the size of the initiative and the frequency of project delivery within the organisation will guide the selection of the appropriate software package for managing the project.

No matter what software is selected and how many software packages are used to manage the project, it is essential that the following aspects (presented here in alphabetical order) are recorded, tracked and managed:

• Assumptions

• Change Records

• Change Requests

• Constraints

• Decisions

• Delivered Risks

• Delivery Risks

• Estimates

• Invoices

• Issues

• Locations

• Projects

• Purchase Orders

• Requirements

• Resources

• Schedules

• Scope Elements

• Stakeholders

• Teams

• Vendors

Not too many products on the market offer an affordable way to manage all of these project elements, however everyday spreadsheet or database tools can be readily employed to create an effective solution.

Having everything in one place will make things easy to find and will encourage regular review and updates.

Smart Start Consulting has developed a technically simple and comprehensive tool that can be provided to clients. 

Please continue to browse this page to find other posts designed to help with IT project management.

I often hear the statement that "people don't know how to estimate".

This is sometimes said because elements are omitted through oversight or lack of understanding, producing an estimate that is seen as too low. Alternatively, too much contingency is included, or is included as a lump sum without attribution to any one particular element of the project, thereby resulting in an estimate that is seen as too high.

I see many project estimates cut back from a cost and time perspective based on a perception that they won't get approved in their initial form. It is unsurprising then that some projects go over budget and over time when both of these were reduced before the project began.

Everyone wants their project to get approved, but it is counter-productive to go in with a low cost and time estimate only to have to ask for more money and time half way into the project. Generally these requests bring about stress, are met with resistance and often another project will need to be slowed or stopped to make the money available.

On the other hand, although projects have multiple risks, it is uncommon for every risk to materialise. If significant contingency is included for each and every perceived risk then the estimate in all likelihood will be too high and is likely not to be approved.

So, what is the answer?

The way to overcome this dilemma is to prepare the estimate with contingency to cover only the key risks and highlight the remaining risks plus the costs to mitigate them.

The project is more likely to be approved, funding won't be tied up where it ultimately won't be needed and there will be less surprise when additional money or time are requested.

Please continue to browse this page to find other posts designed to help with IT project management.

Yes, you can make the right decision, but it will be made easier with experienced guidance.

Choosing the right ERP (Enterprise Resource Planning) solution can be a challenging task, especially in the small and medium business arena, due to the overwhelming amount of choice.

The number of players in this market has exploded in recent years and it can be very difficult to know where to start, let alone know how to go about the implementation.

A critical decision that the business owner needs to make is whether the business processes warrant the selection of an industry aligned solution or one that is more generic.

If the decision is made to go with an industry aligned solution then the choices available are automatically restricted. This can be a good thing as the field is smaller and the process of identifying the preferred solution can be quicker.

The downside is that the strong contenders outside the shortlist are immediately eliminated from the selection process. This means that, although you will have access to some attractive features specific to you industry, some market leading offerings might not be available for consideration.

Also, if an industry aligned solution is being considered, it will be important to understand whether a premium is being charged for the industry specific features and it will also be important to confirm whether these features are deal-breakers if not obtained.

Procuring and implementing an ERP solution is costly and time consuming and therefore a vital early step in the process of selecting an ERP solution is to understand why the ERP is needed in the first place and to understand what alternatives exist.

Is the business a start-up of has it been running for some time?

If it is a new business then the ERP decision will possibly end up being made based on very little understanding of the longer term purpose of the ERP. In this situation a ‘walk before you run’ mindset is beneficial. It will be important to ensure, as a minimum, that the core business processes are addressed by the solution and it can initially be worthwhile to restrict the breadth of business processes to be catered for by the ERP solution. Broadening out to the full set of business processes can occur down the track.

If the business is more mature then the challenge here will be to be very clear about the issues that exist with the ERP solution currently in place. It can be tempting to upgrade to attempt to resolve issues being experienced without getting to the bottom of the issues themselves.

It is easy to blame the software, saying that it doesn’t do what the business wants. What needs to be understood is that many ERP solutions embed good business practices and it is often the existing business practices that need to be changed rather than the existing software.

It is not uncommon for business processes to be changed to reflect the incoming ERP solution, only to find that the issues go away before the new ERP solution is implemented.

These and many other challenges surround the process of selecting your ERP solution. Working with an experienced practitioner who can guide your ERP solution selection can set you on the path to success.

Contact Smart Start Consulting to start your project right!

Please continue to browse this page to find other posts designed to help with IT project management.

As project managers we are always very attune to risks and the impacts they can have on our projects if they materialise and become issues. Our training and experience tell us that we need to be constantly on the lookout for factors in our environment that can adversely affect our planned activities.

Once we have identified a risk, we need to assess the likelihood and impact and determine a way to mitigate the risk. That is to say, we need to identify actions that will reduce or remove the risk.

In some cases it might not be easy to see how a risk can be mitigated. In these cases it can be tempting to state that the risk will be mitigated by being vigilant to the risk, to maintain visibility of the source of the risk and to review the risk frequently.

These activities, although helpful, don’t reduce the size of the threat to the project and might only put us in a better position to react when the risk develops into an issue.

As an example, our project might be reliant on a Subject Matter Expert (SME) who has been assigned to other work. We could propose that we will mitigate this risk by keeping in close touch with the manager of the other work and reminding them of the dependency we have on the SME.

By doing this we are essentially hoping that the SME will be assigned to our project when we need them. There might be no guarantee that we will get access to this person and it is highly possible that the work on the other project will get delayed, thus delaying the availability of the SME for our project.

The best way to manage a risk is to remove it.

In the case above, rather than crossing our fingers and hoping for the best, a better approach will be to set about independently sourcing our own SME. Generally, the best risk mitigations will be those that follow a different path to the risk itself.

Please continue to browse this page to find other posts designed to help with IT project management.

As project managers we describe risks and we identify the activities we need to conduct to remove or minimise the potential impact of these. Mitigating risks doesn't mean crossing your fingers.

Some risks are generic and relate to any project. Common examples are shortage of resources and lack of stakeholder engagement. These risks are essentially a given on any project and it goes without saying that we will manage these risks.

Real value is added by us however when we identify additional risks that apply only to the one particular project that is the subject of our attention right now. If we are managing, for example, a project that will migrate software applications from one data centre to another (eg. to the cloud), there will be risks that are specific to that project and not to others.

Examples of risks pertinent to this project will be the risk of capacity at the destination data centre being insufficient, the risk of not being able to identify the service owner for many applications or the risk of damage occurring to hardware if it needs to be transported.

This becomes a good test of how thoroughly we have reviewed the risks on the project. We need to ask ourselves and others: What risks relate specifically to this project?

Without doing this we are paying lip service to risk management and are in danger of being burned by circumstances that have not been adequately considered.

Please continue to browse this page to find other posts designed to help with IT project management.