A new default skin will be introducted in our next version (4.8). All users who are currently set with the "Classic Blue" skin (the default right now) will see the new skin as soon as they get upgraded.

Michel, our graphic designer, has been working hard on that skin for quite a while. The skin is still under development, but should pretty much look like this:

The header tabs look more modern, as they have no rounded corners. We also added a touch of our logo to the skin. Actually, Michel decided to use the circled arrow's red for the "Print the Main Page" button.

Furthermore, the skin uses our upcoming new website's colors.

Feedback is always appreciated! 

Connect with Sylvain Traversy and the AceProject team via Facebook, LinkedIn and Twitter. 

By Cameron Watson, QAIassist

Context

From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software.

A number of lifecycles have been developed to address specific disciplines within IT – examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC). In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables.

Software Development Lifecycle (SDLC)

The SDLC is used by application development and support teams to develop and maintain computer applications and systems. It is used across an organization and is applied from the inception of a through a successful implementation of the required solution. Though a multitude of SDLC’s exist, the majority of them rely a phased approach, pre-defined deliverables, and standard naming conventions. It will execute in parallel and concurrently with a software testing lifecycle (STLC). The following provides an overview and explanation of the sequenced phases of a generic software development lifecycle (SDLC).

Systems Analysis

The Systems Analysis phase is the first phase to be performed within an SDLC. It is initiated only and in conjunction with a project being authorized or approved. Its purpose is to ensure the requirements to satisfy a business need have been identified and translated into a notational form or models. Once documented, project teams (business and technical staff) utilize the requirements to ensure a common understanding is achieved and to verify the requirements are attainable. As an iterative process, the Systems Analysis phase ensures the project team members are working together to define and clarify the business need and promoting alternatives that could be utilized to address the business need.

Design

The Design phase ensures the application is designed according to the authorized requirements generated during the Systems Analysis phase. The Design phase focuses on the refinement and further granularity of the data, application and technology models defined in the Systems Analysis phase and incorporates other factors that must be considered in designing the solution (e.g. data and non-functional requirements, testing strategy). The solution designed is refined to a level (ie functional specification) where individual software, hardware and data components are defined and documented. When this phase is complete, it will be possible to generate comprehensive time and resource estimates for delivering the application and the necessary business functionality.

Build

The Build phase ensures the following:

1. The application is being built in accordance with the business requirements that were prepared and refined during the Systems Analysis phase
2. The technical and functional standards, as well as design elements of the business solution prepared during the Design phase are used as the basis for developing and testing the product.

The aim of the Build phase is to produce readable, testable and maintainable code for the application in a non-production environment.

Test

The Test phase ensures:

1. The technical code created during the Build phase adheres to the business requirements that were developed and evolved since the beginning of the project
2. The technical code adheres to the design standards prepared during the Design phase.

The aim is to ensure the code built in a non-production environment is viable and can be tested by the end users to assess its ability to satisfy the business need.

Release

The Release phase ensures the application has been satisfactorily tested and satisfies the business need. Once satisfying these criteria the application can be placed into the production environment and utilized by the user community in a production environment.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

From the initial days of Information Technology (IT), practitioners have always recognized the need to establish and apply a suite of industry recognized best practices. One of these best practices is used to develop and maintain computer applications. This is the cycle of life for software.

A number of lifecycles have been developed to address specific disciplines within IT – examples include Project Management Lifecycle (PMLC), Software Development Lifecycle (SDLC), and Software Testing Lifecycle (STLC). In all cases, these lifecycles are made up of a number of phases, each containing a set of deliverables.

Project Management Lifecycle (PMLC)

The project management life cycle (PMLC) is used to initiate, plan, oversee and deliver IT applications and systems from inception to fully operational in a production environment. It is used across an organization and is applied from the beginning of a project (development or maintenance) through a successful implementation of the required solution. Though a multitude of PMLC’s exist, they commonly rely on and are executed using a “phased” approach, pre-defined deliverables, and standard naming conventions. The project management lifecycle (PMLC) traditionally acts to guide the software development lifecycle (SDLC) and the software testing lifecycle (SDLC).

The following provides an overview and explanation of the sequenced phases of a generic project management lifecycle (PMLC).

Initiate

Initiate is the first phase to be performed within the project management lifecycle (PMLC). It is the process of formally recognizing that a project exists and has been authorized to continue. The purpose of this phase is twofold :

• First, to assess and determine a business need.
• Second, to translate high-level business requirements into a set of requirements from which the project team will build the product and confirm the requirements can be fulfilled.

This iterative process is lead by the project manager who requires input and expertise from both business and technical IT resources assigned to the project.

Plan

The Plan phase is executed upon the authorization of a project. It is an iterative process used by a project manager to devise, maintain and execute a workable plan to ensure the business solution is effectively implemented. The workable plan must address:

• Project scope
• Resource requirements, project team roles
• Deliverables to be prepared throughout the project
• A schedule to define how and when the project will be completed
• The activities to be applied to ensure quality is incorporated into the implemented solution

Execute and Control

The Execute & Control phase is an iterative process that aims at coordinating the activities of the project team resources to ensure the project can be completed according to the project plan. The progress of the project activities are monitored against the project plan, and the appropriate corrective action are taken when the project is deviating from project plan. The Project Manager prepares and utilizes a number of specific deliverables to ensure project procedures are available to the project team, the project management deliverables are maintained throughout the life of the project, deviations to scope, schedule and resources are addressed in a timely fashion.

Closure

Closure is the final phase of the project management lifecycle. Its purpose is to document a true reflection of how the project evolved from start date through to its completion so that future projects can benefit from the knowledge and experience gained on the project. Future project teams can then leverage this knowledge to increase the efficiencies on delivering business solutions to their clients.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Although I have worked and consulted with a multitude of organizations throughout my career, I am always intrigued at how many varied understandings and opinions there are for the term deliverable.  In some organizations the term deliverable doesn’t even exist. In other organizations, it is relied upon to build and maintain every product and application.

Here’s my take on the concept: A deliverable is a tangible, quantifiable and measureable package of work.  

• Each deliverable has a specific purpose and context.
• It is a unique component, along with other deliverables, of a lifecycle/methodology.
• It supports and is referenced by other deliverables of the lifecycle/methodology.
• It has pre-defined requirements.
• It is created based on the unique characteristics of a product or project.
• Its information acts as the basis for maintaining a product or project.
• It can be verified, reviewed and approved on its own merit. 

The following principles are applicable to deliverables 

Cohesion/Integrity - Each deliverable acts as a building block to establish and bolster additional information needed as the product or project evolves.

Pre-established Informational Needs – the purpose for each deliverable is unique as is the informational requirements to complete it.

Scalability – the deliverables and the information used to populate them must be scalable to the characteristics of each specific project.

Creation/Review/Approval – each deliverable is prepared based on the required informational needs. The deliverable can be created, reviewed and approved based on its own merit.

Project Planning/Oversight – due to each deliverable having pre-defined and finite informational requirements, they can be incorporated as a measureable and quantifiable piece of work to be defined as part of a project plan and reflected on a project schedule.  Project oversight can be maintained by assessing the status and completion of the deliverables as they are created, reviewed, and approved. 

Applying a deliverable-based lifecycle/methodology provides an organization the ability to leverage a standard process that can be applied by all project teams to develop and maintain applications. Project managers can then  focus on delivery rather than  micro-managing the activities a project team member  is to perform to complete those deliverables.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

I was invited out to lunch last week by an old friend and colleague. We had worked at the same organization many years ago and had stayed in touch throughout the years. Once seated and our meals ordered, he broke the news. He had recently accepted a senior management position at a reputed fortune 500 company’ His role would be to guide the project managed office (PMO) for the company.

After receiving my congratulations, a somber and concerned look came over his face – he stated “I think I have just made a serious error with regard to my career.”

As we discussed things further I began to gain an appreciation for his statement.  He drew an analogy to a train wreck that gets replayed day after day after day – a perpetual circle of point the finger and lay the blame – without a beginning and without an end.

He began citing a number of instances.

• The users were in a constant state of wondering why changes to existing applications took so long.
• The IT application maintenance staff did not have any documentation to scope or verify changes being made.
• The development staff were creating applications in days without reviewing the development iterations with the user community.
• Testing (of any kind) was not performed on any of the applications being placed into the production environment.

As a result, the work environment became tainted with a “watch your behind,” “never trust a user”, “never trust a tech” mentality. Upon completing the description he looked at me with a bewildered look and said “what am I going to do ?”  I asked “what IT methodology is the organization using?” He responded “there is no recognized or formal IT methodology being used. Every project and maintenance team has their own approach and none of them are documented or communicated to the user community”.

I told him the more difficult the problem the simpler the solution must be.  I suggested that he could do one of two things.

1.       He could call his boss from his previous position and get his old job back;

2.       He could accept his new organization for what it was and make an effort to turn things around and point it in the right direction.

He acknowledged my point and we started down another tangent talking about what could be done at his new position to remedy the situation. He told me “the floor is mine” and asked for suggestions on how I would address things. I said that my most immediate concern would be the poor communication between the various departments and staff in the organization. Poor internal communications is often the root cause for a culture of finger pointing and lack of accountability. Then, I mentioned that the lack of formal IT methodology appeared to be the most significant deficiency within the organization.

Although many people subscribe to the notion that an IT methodology is used to consistently deliver quality applications in a timely manner, it can also provide additional benefits to an organization. More specifically, it would

• Provide a common tool and language that organizational staff (business and IT) can utilize for developing and maintaining applications;
• Create a framework that organizational resources could leverage to perform project management, software development & maintenance, and software testing;
• Establish a deliverable-based and scalable process to address a multitude of IT projects to ensure organizational resources could be proficient on a multitude of applications in a multitude of environments.

As we left the eatery he thanked me for getting out to lunch with him and was appreciative that I was able to toss my two cents into the discussion. I then asked him if he was going to call his old boss back. He smiled with a glint in his eye and said, “no way – there is an organization that has to be saved and I’ve got to start that effort this very afternoon.”

Suffice it to say, I am looking forward to getting back out to lunch with him in a month or so. I am interested to hear how his effort is going and hoping to be able to add another two cents. I’ll keep you posted.

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

Context

One of the questions I am asked most frequently is “What is the most important deliverable of an IT methodology”?

The simplest answer is “it depends”. The more appropriate answer is “it depends on the scope of the project, whether a project team has been assembled, whether the project has been approved, if user requirements have been defined, what the technical alternatives are, when the project has to be completed, if the business users have been trained, etc, etc, etc”.

Every project is different. Every project stakeholder is different. Every project team is different. Every deadline is different. The uniqueness and dynamics of these ever changing variables ensures the “deliverable” deemed “most important” will change as the project and project team evolves. When I am faced with this question I usually try and respond with a story about Snow White and the Seven Dwarfs.

Stew Anyone

Once upon a time Snow White had invited all of the dwarfs over to her place for dinner. The first thing to meet the dwarfs upon their arrival was the smell emanating from the kitchen – its aroma was delightful and they kept asking Snow White what was for dinner. After some coaxing Snow White revealed that she had made up a pot of stew.

The Dwarfs conceded that they did not know what stew was and wanted Snow White to tell them what the ingredients were. Snow White relented and said “my stew is made up of a number of things – roast beef, potatoes, carrots, yams, peas, barley, celery.” Snow White then invited the Dwarfs into the kitchen to look into the pot as the stew simmered. The Dwarfs were so excited to see the stew and each of them kept telling Snow White they could not wait to try it. They all promised they would eat all of their stew.

After viewing/smelling the stew, Snow White told the Dwarfs to find their seats at the dining room table she had set and she would bring the stew out for everyone to enjoy. The Dwarfs gleefully found their spots at the table and were eagerly awaiting Snow White to arrive from the kitchen. Snow White entered the dining with a huge bowl of stew and told the dwarfs to help themselves to a serving while she went back to the kitchen to get the salad, the buns and to make sure she had turned off the oven.

Upon her return to the dining room, Snow White was pleased to see the hungry dwarfs devouring their dinner and asked if they were enjoying the stew. Their collective response was a resounding “yes!” In hearing this praise, Snow White sat down at her place at the table to recognize a most disconcerting reality - Sleepy had only the roast beef on his plate, Dopey had only the potatoes on his plate, Sneezy had only the carrots on his plate, Happy had only the yams on his plate, Grumpy had all only the peas on his plate, Bashful had only the barley on his plate, and Doc had only the celery on his plate.

Upset, Snow White confronted the Dwarfs saying: “Why did you separate all of the ingredients in the stew?” Each of the Dwarfs responded with the same answer: “We each knew what we liked and knew we would enjoy our own if we separated the ingredients.”

Snow White got up from the table, went back to the kitchen and returned with another large bowl of stew. This time she served the Dwarfs herself – each receiving a plate full of all the ingredients. After a little encouragement each of the Dwarfs tried the new concoction – with every mouthful the smiles on their faces got broader and broader. The Dwarfs had come to realize that the combination of all the ingredients was the secret to success.

Moral of the Story

Although an IT methodology is made up of specific and unique deliverables, its true value is best realized when the all deliverables are used together throughout the life of the project. An authorized User Acceptance Test Authorization deliverable utilized at the completion of a project is no more or less important than the Project Charter that was created to initiate the same project.

Bon Appetit!

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

By Cameron Watson, QAIassist

The project charter has been around for as long as the concept of work.

The Egyptians used project charters to create the Pyramids. So did the Greeks to erect the Parthenon. Even the Romans used a project charter to create the Coliseum. Little Johnny used a project charter to construct his miniature house made of lego blocks.

As different as the times and methods used to create these structures were, one common thread exists - success was based on the creation, maintenance and oversight of a project charter. The Egyptians may have created theirs with hieroglyphics in the sand, the Greeks may have chiseled theirs in Mount Olympus, the Romans may have penned theirs in Latin, and little Johnny may have used crayola on the kitchen table. The point is not how complex or sophisticated the project charter was, but rather, that one was required, prepared and relied upon to act as a foundation to create all of these structures.

While academia can spend days crafting a definition of the complexities and internal dynamics of a project charter, anyone can define it in five simple words: "what are we trying to do?"

Though the term project charter is routinely applied and recognized within the Information Technology (IT) industry, the concept of project charter is as applicable to organizational strategic planning, corporate budgeting and operational oversight. It is difficult to fathom a corporate president  or  CEO performing their roles without defining and documenting "what are we trying to do?" or a CFO maintaining fiscal control without defining and documenting "what are we trying to do?"

The concept of "what are we trying to do?" permeates every facet of every organization. Suffice it to say, the tenure of a CEO would not be very long if they were unable to articulate and gain approval of "what are we trying to do?" from the shareholders.

On the surface, addressing the project charter "what are we trying to do?" question appears to be a simple exercise, be it a CEO, CFO or an IT Project Manager. In reality, it can become a  very trying and taxing exercise. The amount of definition and explanation required in a project charter depends upon the magnitude and complexity of the "what are we trying to do?" question. A project charter used to document how one person should dig a hole in the ground could be documented on half a sheet of paper, while a project charter used to document how to send a space craft to the moon and back would span  many pages. 

The utilization of a project charter is as varied as the number of organizations that create and apply them. In some cases the project charter is the project’s bible and is relied upon throughout the project. In others cases, the project charter is a project title and a brief project description. The project charter has been adapted and customized by organizations to address a myriad of needs. Here are a few contexts where the project charter is used.

Corporate - Project Definition
As an initial project document, the project charter establishes the goal posts from which the project will be initiated, planned, pursued and completed.  The project’s definition will reflect its size and complexity. It can include the following:

• The purpose of the project
• The scope
• The objectives
• The resources (HR and otherwise) to be utilized on the project
• The plan
• The cost estimate
• Project hierarchy and organization
• Risks and impacts the project will have on the organization.

 The project charter is not a stagnate document, it evolves and is maintained to reflect the changing circumstances and conditions associated with the project. The project charter acts to establish the project context and boundaries to ensure all project team stakeholders and resources have a common point of reference and understanding of the project throughout its duration.

Corporate - Project Authorization
The project charter gives organizational stakeholders the ability to review and evaluate priorities. Utilizing the project charter to obtain formal authorization ensures there is a correlation between the corporate strategy, planning and budgeting exercises and the organizational resources allocated to complete a project. This ensures organizational resources will remained focused on the authorized projects.

Corporate - Project Scope Management
After establishing the project context and boundaries and receiving formal authorization, the project charter can be used to monitor and evaluate the scope of the project from beginning to end. Project stakeholders are able to reference the project charter to monitor the project progress and direction in relation to the original context and boundaries they had originally approved. This affords project stakeholders the flexibility to stop, defer or accelerate IT project team priorities to better reflect organizational business needs. It also enables IT project team resources the ability to re-calibrate their efforts based on decisions and approvals of organizational stakeholders. 

Corporate - Formal Deliverable
The project charter establishes an operational premise to promote structure and formal documentation. This is very important to the efficiency of IT delivery and support. This concept of structure and documentation can be leveraged by the organization to introduce quality assurance and to improve the maintenance and support of  applications.

Project  - Planning & Oversight Benchmark
Once authorized, the project charter can act as the basis for a project planning exercise. The Project Manager is able to reference the original definitions established and authorized in the project charter to provide greater clarity and detail on how the project will be executed. Project plans, project schedules, project resources, project budget allocations are derived from the authorized project charter.

Project - Team Communication
The authorized project charter provides the mechanism the project team will rely on throughout the life of the project. It acts as the basis for the deliverables and wok products identified in the project plan and project schedule. Having formal documentation prepared provides several benefits. Project development teams will have access to the necessary information to ensure project team communication is consistent and based on formal approvals - all project development team members can rely on the authorized deliverables to ensure they are working off the same page. Application support and maintenance teams have a common point of reference they can leverage to effectively maintain and incorporate new functionality into the applications.

Wrap Up
Although the concept and need to create a project charter has meant different things in different environments for different audiences, its primary purpose has remained the same. Be it the Egyptians or Little Johnny, as long as the concept of work exists, we will need to know "what are we trying to do?"

About QAIassist

QAIassist helps organizations increase and optimize their IT delivery and support efficiency. QAIassist's Integrated Methodology incorporates the disciplines and deliverables required for organizations to consistently deliver quality applications on time and within budget. Visit QAIassist's website or email Cameron for more information.

It's that time of year again: most of us are getting ready to a well-deserved break from projects and business.

On behalf of the whole team, I would like to give you my warmest wishes for the holiday season and the coming year.

Yes, we're taking a break too!

We would like to inform you that the AceProject team is taking a break during the holidays. Our offices will be closed from December 24nd, reopening January 5th.

If you encounter an emergency during this period, please send an email support@aceproject.com. We will keep an eye on our inbox during that period.

Note that our servers will remain online during this period. There will be no interruption of service for Hosted accounts.

Thank you for using AceProject

AceProject would not be the success it is today without you. We would like to thank you for using AceProject.

Connect with Karine Simard and the AceProject team via Facebook, LinkedIn and Twitter.