What goes around comes around.

Recently I attended a networking group to network with a variety of IT and business professionals. It just happened that a project manager and quality assurance specialist stopped me to chat. The project manager made a comment that he had read my book several years back and that it was useful not only for understanding configuration management but it was useful for a recent interview he had in pursuit of a contract to manage an eReader development project.

As I had another engagement to make and was accompanied by a colleague, I asked why? He said it was about understanding the chip development process as your book states for firmware configuration management/development. I smiled and just made the quick statement: What goes around comes around. Thanks and glad the book has been useful through the years and into the 21^st century”. I have to be going but lets talk and share more the next time we meet, and by the way take a look at itprofessionalfacilitator.com.

The colleague with me stated, “Not bad”, what do you think?” I said that’s what it is all about, sharing the knowledge and lessons learned, and best practices. But my thoughts were also on another item. I had a call from  a recruiter representing a company in New York about eReader/eBook, web development opportunity.. It was only at the Project Management level and not at the program management level with the responsibility for the program, managing project managers and may include the PMO. Although my pursuit has been program manager or director level responsibility to include ensuring the success of system/application or web development projects, I understood when that project manager said that it (the book) had been useful to understand not only Configuration Management (CM) but firmware (embedded systems/applications) development as part of the eReader development/product project.

The IT Industry has Accepted Failure as the Norm

I recently wrote an article, significant to the IT industry, that was published in TechRepublic.

Click here for more information.

Program and Project Management Planning and Execution

Technology Project and Program Management

When considering planning for Program/Project Management, the Development Process/Methodologies, Configuration Management (including Requirements and Release Management), and Quality Assurance (Verification & Validation/Test),Best Practice Processes (BPPs), you must establish effective best (and good) practices.

The use of Best (and) Good practices ensures that H.O.P.E. (High Octane (Performing) Program/Project Execution would be the result of effective and realistic Initiation and Planning to increase the likely hood of success.

Conducting Large Scale Assessments and Gap Analysis

Technology Project Management

When you do an assessment and gap analysis you must consider:

1.      Business Processes (systems, policies, contracts, business rules, procedures, SOPs, etc.),

2.      Organization (Change, Culture, etc.)

3.      People (Skills, Training, etc.), and

4.      Technology (systems, applications, data/databases, interfaces, etc.)

5.      And must assess the supporting methodologies (program and program, and system development) infrastructure (desktop, servers, communications network, etc.)

Consider that on average, large scale, assessment will average 4-6 months.

The SDLC and How Program and Project Management Applies

Technology Project Management

My latest question that I answered in,

http://www.techrepublic.com/forum/questions/101-215110?tag=mantle_skin;content

Sorry, I only joined as an expert with techrepublic only recently but I would have wanted to answer and respond to the below question. I say never too late but it may be. I was concerned because I did not see an answer to this most important question. Just in case someone else has the below question, I will provide my answer to the question.

Project Management

“Hey there, im studying SDLC’s, can someone please give me there definitions of Project management, and how it is implemented in the system development life cycle (not software development lifecycle)”

My comments:

Yes, good study area. When you refer to the SDLC, originally known as the system development life cycle, it is also currently known as the System/Software Development Life Cycle (SDLC). Often the software development portion of it is used for software and application development of a single product, software system or application. See if your study verifies this.

If I am correct, you want the perspective of the system development life cycle as a whole and how project management fits within this context. This link here provides a diagram of the SDLC and reflects the integration of how /where project and program management applies. This diagram also reflects how configuration management and quality assurance’s verification and validation are integrated within the SDLC. LinkLDamon this link has to be put in after you change the URL or leave as I change it or suggest another one to show “system”.

Program and Project Management does apply to the system (and software) development life cycle. See links below for a definition and explanation of project management. There is a definition/explanation for Program Management as well. Both of these management disciplines apply to the SDLC. It is Program management that applies to the system as a whole and it is project managers (project management) that manage each subsystem/component of the system. It is an allocation or breakdown of the system into subsystems, components, and other major components that become projects to be developed and integrated, or delivered to be integrated, into the system. You also may have subcontractors or vendors developing development and/or delivering components of the system that may be projects. These deliverables are integrated into the system as well during system integration before system testing and qualification.

Additional Resources:

1. Responsibilities of a Project and Program Manager
2. Project and Program Management Differences

But remember, within the System Development Life Cycle lies the software and hardware (subsystems or components of the system) development life cycles. The software could be software and/or firmware (embedded program systems).I hope that is helpful and useful for your studying.

Three Tips to Idenity Project and Program Risks

Technology Project and Program Management

I was reading another article about identifying or handling project risks:

http://www.techrepublic.com/blog/five-tips/five-tips-for-handling-project-risks/534?tag=mantle_skin;content

Although it seems to be presenting activities of risk identification and management, and not tips, it was interesting.

But I would like to present three tips to identify project and program risks

 
Three tips (perspectives) to identify/uncover risks for IT projects and programs.

Identify possible/potential risks based on:

1. The technology being developed and introduced to the organization and user community, impact on the organization, other processes (or systems and their interfaces) and people
2. The project or program scope, its approved budget(s), the project plan and schedules, resources (manpower, money, equipment, etc), procurement and subcontractors/vendors
3. The System/System Development Life Cycle (SDLC) i.e., requirements identification and analysis, Architecture/Detail Design, Development, System Test, Delivery/Deployment)

 

IT Project and Program Teams (and Individual Members) Require Acknowledgement and Recognition...

Technology Project Management

 

IT Project and Program Teams (and individual members) require Acknowledgement and Recognition ...

because without them their would be no success!

It’s about Team Success! I enjoyed and I am enjoying my career as a member of those teams.

I was proud to be a member of the teams: IT project and program teams built by the project or program manager and team Leads (Business and Technical). I appreciated the teams very much. And with their success came the acknowledgement and recognition they deserved as a team and as individual members.

Management, Project and Program Managers and team Leads must never forget this fact: That unless you are a "one man "show" success does not come without team success. That success, the team’s success, my success, I attribute to committed team members (empowered team members), with knowledge transferred by their interactions, and through their use of lessons learned and Best Practice Processes' (BPPs’) best practices. The teams, with the appropriate methodologies, were proactive to address potential problems, issues and risks with open communication throughout the projects and programs.

And even with their individual goals they were teams that were committed to the primary Goals and Objectives of the projects and programs.