The PERT Analysis – Part 1

For every project, there are tasks that are outlined which serve as an indication of what needs to be completed and in what order to ensure the proper outcome and closure of the project. This can be expanded upon further in the concept of a program, which is a group of inter-related projects.

As a program and its constituent projects become more complex, inter-dependencies of tasks and project deliverables become an important piece of criteria to track. Successful completion of a project or program that has dependencies is a challenging endeavor. Care and diligence on the part of the project manager is paramount to ensure that specific dependencies are resourced and completed accordingly to ensure that other pieces of the overall project or program and also be initiated and eventually completed.

When it comes to properly cataloging and tracking project/program flow and interdependencies, it becomes imperative to do so effectively. With that being said, what is the best tool in the project manager’s arsenal to accomplish this task?

Program Evaluation and Review Technique

The Program Evaluation and Review Technique, or ‘PERT‘ for short, is a statistical tool and technique that is specifically designed to define, analyze, track and effectively represent the various constituent pieces of a project or program. It is mostly commonly used in conjunction with the critical path method (CPM) which is a technique used to schedule a set of project activities.

The main criteria for performing an effective PERT is to have the tasks, projects, interdependencies and timeframes all catalogued. Normally, this process will occur early in the project plan, regardless of inherent project process. The Work Breakdown Structure will generally drill down the project or program into its constituent task level activities. From there, each task can be given a timeframe for completion. (Note: for information on how to perform project scheduling and timeframe calculations, please consult the post: Project Scheduling-Tools & Techniques)

Once the various pieces are itemized, the PERT structure can be formed. The following are terminology definitions of the various pieces of the PERT that are used to produce the eventual visual chart are as follows:

PERT Event – Signifies the start or completion of an activity (task)

Predecessor Event – Precedes a given event but has no intervening events

Successor Event – Follows a given event but has no intervening events

A few key points in regards to the above definitions. The standard PERT Event consumes no resources and takes no time; it is merely used to signify the node of completion for various tasks. With regards to the predecessor and successor events, note that they can have any number of predecessors or successors within the entire structure.

Once the key attributes of the PERT analysis are itemized and catalogued, an actual dependency chart can be drafted to signify the overall flow of the project or program. As an example, consider the following:

A project has six activities, labelled A, B, C, D, E and F. Each activity has been given the following timelines for completion:

A=3wk

B=4wk

C=1wk

D=2wk

E=2wk

F=3wk

Each of the activities have varying dependencies that are displayed graphically as follows:

Once the activities are accurately drafted, with their inherent completion times and dependencies provided, the overall graph yields the estimated time for completion of the project. This estimate is referred to as the ‘critical path‘ and it denotes the longest path and timeframe based on the chart. In order to determine the critical path, all paths from the chart are evaluated with their completion times added together. So as per the above example, the paths and their mathematical sums are as follows:

A->D = (3+2)= 5wks

B->E = (4+2) = 6wks

A->C->F = (3+1+3) = 7wks

Thus, the longest timeframe or ‘critical path’ is A->C->F which is 7wks. Which denotes the overall time to complete the project.

Conclusions

The PERT method is an excellent mechanism to graphically display the primary project dependencies and overall flow. It is a high level overview that gives a good summation of project estimated completion time and overall variance. While PERT is valuable in demonstrating specific dependencies and overall project flow, it may become cumbersome if there are copious interdependencies in the overall project or program. In those cases, it may be advantageous to create multiple PERT charts denoting various sections of the project and then have those critical path estimates serve up to a global PERT that demonstrates the overall project or program flow and completion.

In the next post, we will delve into PERT and critical path further by discussing floats, fast tracking and earliest/latest start and finish times.

Project Management of Mobile Applications

mobiledevicesAs most are fully aware, our world is rapidly being transformed by the increasing prevalence of ‘smart’ devices that are carried around on our persons. Mobile phones, tablets and now wearable tech like Google Glasses or SmartWatches are providing consumers with new products to explore and new ancillary applications to utilize.

The wave of new devices has produced a veritable plethora of new utilities that users can leverage, whether they be mapping applications, social network widgets or simple games. There is not much of a limit on the type and nature of usable software on the myriad of smart phones and tablets that are available nowadays.

From the standpoint of producing an actual mobile application that is then made available to the consumer, the process to follow from a project management perspective is somewhat akin to other development activities, but with a few key differences. This post will attempt to cover some of the dos and don’t of effective project management in the mobile space.

A Word on Mobile & Tablet Technologies

There are various companies that produce various software packages for use on mobile devices along with many vendors who produce the hardware that these varied software applications utilize. In many cases, the vendors of the hardware also produce software for their own units, as might be expected. To provide a brief pre-amble to the discussion, here is a list of the various companies involved in the mobile space:

1. Apple – Produces the iOS operating system for use exclusively on iPhones and iPads. Also responsible for the creation and distribution of the hardware inherent to these devices. (Through third party contracts) The primary development language in use is Objective C.

2. Google – Produces the Android operating system and makes the OS available to everyone. Also owns the former Motorola Mobile Hardware division and uses that to produce its own hardware leveraging its own operating system. The primary development language in use is Java, an open source programming language now maintained by Oracle.

3. Microsoft – Produces Windows Mobile operating system, a derivative of the common Windows OS in use on many desktop computers. Has partnerships with Nokia on the creation of hardware to distribute Windows phones and also creates hardware of its own, primarily in the tablet space, such as the Surface product line. The primary development language in use is .NET, with most developers opting to use C#, an exclusive proprietary derivative of C++.

4. Blackberry (formerly RIMM) – Produces the Blackberry operating system for exclusive use on its Blackberry devices. Also produces its own hardware, mostly nowadays just relegated to mobile phones. The Blackberry platform supports a variety of different programming languages that one can leverage, including C/C++, JavaScript, ActionScript and Java.

Additional note: there are numerous vendors that also produce hardware leveraging some of the technologies listed above. The most prominent operating system being used is Android, and that is being leveraged by companies such as Samsung, HTC, LG, Kyocera, and Casio.

Application Development for Mobile Devices

Development for mobile devices in an of itself is not entirely different from development in other spaces. As indicated above, many of the technologies that are used in both application or web development are portable for use on mobile devices. There are however, some key differences that need to be noted in regards to producing applications for use on mobile devices:

Generic Platform Development – While many individuals working on mobile development may opt to use the standard toolkits as they are individually for mobile devices, there are options that exist that will allow one to potentially write generic code that can be built and distributed across a variety of different device types. Several mechanisms exist that provide a singular way to write and publish code that can function on Apple, Android, Windows and other platform types without the need to have to write separate pieces of code for each device. Technologies such as PhoneGap, Titanium and Unity are but a few development toolskits and IDEs that can allow one to keep all code generic enough that it will be easily implemented from one platform to the next.

  • Pros – Keeps coding simple and allows for easy distribution and maintenance of applications
  • Cons – Performance can generally suffer due to abstraction layer of generic engine adding additional ‘weight’ to overall app

Distribution & Development Caveats

One major point to be aware of as it pertains to how one develops and distributes their applications is an understanding of how apps are marketed and downloaded by users. As most are likely aware, depending on your smartphone of choice, one will need to go through the ‘store’ that is made available by the main vendor in order to acquire an application. For Apple, it is the AppStore, for Google, it is GooglePlay and for Microsoft it is Windows Store.

With that being said, development and distribution of mobile applications must go through a vendor review and ratification process before an application is sanctioned for broad-based availability. This means that the development process itself needs to be mindful of the regulations and rules that an app vendor might have as it pertains to what can be distributed in their network. Additionally, as part of overall development, most vendors will have a sandbox area where apps can be uploaded and tested. Utilizing this sandbox is also part of the overall process of getting a particular mobile application ratified.

As the project manager, you will need to be cognizant of all these factors when performing your scheduling activities. Care must be taken to ensure that all policies as dictated by the vendor are followed. It is also advantageous to add flexibility and potentially some padding to the schedule to ensure that adequate time is provided for approval and potential rejection and re-factoring of the application as needed.

Application Maintenance for Mobile Devices

As most owners of Smartphones will already know, the applications you have on your device will generally have an update feature built into them. This can be either automatic or manual. The system is akin to updates of resident applications on personal computers; i.e. as new features and/or fixes are performed to the application, the changes are ‘pushed’ to devices currently leveraging the application.

From the standpoint of your own technology application, you need to be cognizant of these main factors:

  1. Fixes/Updates Need to be Continuous – As changes are made, especially bug fixes, those modifications should be pushed out studiously. Note that to avoid inundating the user with updates, ensure you ‘bulk’ push changes and updates, except in those corner cases where a critical fix is being rolled out.
  2. Keep your App Store Application Up to Date – As changes are being made to your already deployed app, ensure you have a policy in place to make sure the latest version of your application is available on the main download sites. Otherwise, your users will be forced to perform immediate updates to a recently downloaded application, which can be frustrating and gives the impression of a poor release methodology being in place.
  3. Monitor User Sentiment – While this is somewhat in the realm of product management, nonetheless, it is imperative you get a gauge of how your application is being perceived. Most app stores have rating and feedback systems built into their platform and it is important that those channels are monitored. There is actually software available that can track sentiment and feedback put out by users in app store spaces or in other social networking circles such as Facebook or Twitter. Utilizing some of this type of software can help stream effective feedback into actionable items that can be reviewed and acted upon by the team.
  4. Stay Up to Date on New Versions of Mobile Operating Systems – This is probably one of the more overlooked concepts, but it can be exceptionally hazardous if not monitored. Just as you and your team are updating your own application(s), Google, Apple, Microsoft and others are also making changes to their underlying platforms. In some cases, these updates are small, but in other cases, a new operating system is rolled out and like anything, it can be a bumpy ride for app developers. Changes to the underlying platform can cause your application to behave erratically or not function outright. In any case, from the team perspective, it is important to stay abreast of these types of changes and allocate adequate testing as part of the overall application timeline. From the project manager perspective, keeping track of these and other dependencies is of utmost importance.

Conclusion

In most cases, development of mobile applications is not too dissimilar from other software packages created by engineers and developers around the globe. However, there are distinctions as mentioned above that need to be considered an evaluated as part of the overall life-cycle of the application. Being knowledgeable of how things operate in the mobile arena and understanding the differences will allow one to more readily handle the issues that arise with mobile app development and be able to mitigate problems that might manifest.

Follow

Get every new post delivered to your Inbox.

Join 60 other followers