Posted on

“We’ll Make It Project Management”

Some time ago I created a list of different styles of project management (I should have added “don’t try that at home” disclaimer there). Anyway, recently I witnessed yet another flavor, which I’ll call: “we’ll make it project management.” Luckily I view the “stunning” details from a safe distance.

The recipe is simple: no matter what happens we’ll make it. We’ve just cut a schedule in half and added a bunch of new features? But we’ll make it. One third of developers have just left? No problem, we’ll make it. Our engineers barely deal with everyday maintenance leaving aside new implementations? Dude, we’ll make it. We’ve just moved every developer from the project to do firefighting in other deals? We’ll make it, we’ll make it. A meteorite is heading right for our headquarters? You already know: We’ll make it.

The strategy is simple – verbally repeat the “we’ll make it” mantra and do nothing to prepare for incoming failure. The great thing about this project management technique is you don’t stress at all. And you have an easy answer to each question from the project team. Yes, you guessed correctly: “we’ll make it.”

A prerequisite to employ this technique is an overgrown ego. A success story from the distant past also helps. It doesn’t really matter that your project was a hundred times easier to complete and that you were a decade younger and it wasn’t really a glowing triumph at all.  Small details.

So, if you’re a part of a project team where we’ll make it project management is used, well, I can only help with that famous quotation: “Run Forrest, Run!” I should have another story documenting usage of the technique shortly. I’ll share it with you for sure. After all it should be a nice story to read.

 

Author: Pawel Brodzinski

Posted on

How service orientation has paved the way for cloud computing

Service orientation is the successful combination of technology, business processes, and methodologies. Service orientation is especially important to outsourcing firms because it allows them to adjust not only the methodologies that they adopt in producing technologies, as well as the way they run operations. Service orientation is a way for these firms to treat both their internal and external partners as customers. It is not merely about producing technology; it also takes into consideration the enterprise culture and the various business processes involved in creating, improving, and delivering services to clients.

In his book Service Oriented Enterprises, Setrag Khoshafian suggests that in building a service-oriented enterprise, it is important to look at a “bottom up, three-layered infrastructure,” namely:

• Service building blocks, where existing applications can be combined as services to form an SOA implementation
• Composition services, which is a combination of existing services to package a new service
• Business process, which involves either service building blocks or composition services

With these three layers in mind, one should easily understand the importance of streamlining processes, such that there is no need to create entirely new products and services. Instead, project teams have to recognize the needs of clients and put together service or product suites from what are already available. The practice ultimately enables delivery teams to avoid overshooting time and resources. Instead, the focus will be on introducing innovative services to both internal and external customer domains. Ultimately, integration is the key in building SOAs, automating processes, and managing technologies.

The best examples of the popularity and success in adopting SOE is found among web-based businesses, such the most popular e-commerce and social sites. AJAX and the “mashing up” of interfaces and APIs created a trend that three years ago came to be known as Web 2.0. From simple brochure-type web sites into programmable web, SOE gained traction not only among technology producers, but more importantly, among technology consumers. However, the real gem that lies in the midst of this revolution in Web technologies is in understanding the needs of businesses (and their processes) and putting together available packets of applications.

Nowadays, cloud computing and software-as-a-service approaches are off-shoots of SOE as initially made popular in the general public’s consciousness. Large IT firms have found inspiration in Web services to integrate business processes and applications.  At this point, the issues that have plagued the outside technology consuming public provide lessons in Web-inspired or Web-based enterprise computing. Always-on reliability, seamless transaction among applications, and data security are some of the measures enterprises need to establish in conducting internal and external businesses.

Overall, deployment of technology in the enterprise and to customers will be a matter of knowing what is in stock, how it applies to the business processes of both parties, and what measures should be put in place to combine and protect the integrity of these applications.  Linking business rules and process execution allow for more realistic performance measures and better project monitoring and management.

By ExecutiveBrief
www.executivebrief.com

Posted on

Beginning of the End: Defining Project Closure

When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?

Key Components
According to Joe Coley, independent software developer and member of Northeast Dataflex Consortium, “Projects that I’ve been involved with…have been very much subject to additional needs and desires of the user community.” In effect, this means that the end deliverable becomes the focus of the closure plan — that is, to ensure a high level of end user satisfaction with the software requested and therefore created. Coley has 20 years of experience in the information technology industry and offers much insight on the subject. When it comes to key components for successful closure plans, he highlights three main aspects to consider:

• Assess the project requirements. In order to determine the best course of action throughout the cycle of a project, it is necessary to first consider the scope of the project. Establishing a clear outlook and complete understanding as to the required deliverables will greatly improve the ability to adequately determine exactly what tasks must be carried out in order to meet these deliverables in an efficient and timely manner.

• Communication. While communication is always essential throughout the cycle of any project or initiative, it is imperative to establish a specific plan for obtaining end-user input, as needed and where feasible. Therefore, a key component to a successful close is establishing and maintaining open lines of communication with the appropriate groups. The end users comprise the group of those who will be utilizing the software in real-time business applications; they have the critical business knowledge as to ways in which the software can be created or functionality that can be incorporated so that the result will be a valuable tool with the capability to enhance their business functions.

• Offer continuing support. When it comes to considering a focus on the continuing support needs of the end-user community, Coley cites a specific reason to do so, “There is always an expectation of continuing support in the form of application tweaks, bug fixes, and enhancements.” By extending continuing support to the end users, they have more confidence in the software program as well as in their chosen developer.

Any components, however, are unique to each project and must be considered on a individual basis; while there may be similarities among projects, what may have worked well during a project in the past might not be best suited for a current project. Establishing and maintaining a plan with the end user in mind makes for a smoother transition and successful close of a software development project.

 

Full text of the interview with Joe Coley is available here: http://www.executivebrief.com/article/the-beginning-of-the-end-defining-project-closure/.

Posted on

Climbing Mountains

The company I work for is located in Colorado.  And for recreation, we climb mountains.  While climbing one, it occurred to me that you can’t always see what’s over the next one.  There are plenty of obstacles to block your view.  Maybe the next one will be easy.  Or maybe it will kick your butt.

Running a business is like that.  At startup, you’re anxious and ready to go!  You take each hill with blind ambition.  Nothing seems impossible.  You see a few mountains on the horizon, but feel certain they’ll fall by the time you reach them.  But the things you can’t see nag you.

Business is like a mountain

 

A few years into the endeavor, and you are sure it’s licked.  But you really don’t see anything beyond the nearest hill.  Some of your biggest obstacles are yet to come.  And you don’t even know it.  That’s when you need the real stamina.  And the faith to push up that next hill, however high it may be.

What are some obstacles your fledgling business might encounter?  How about this nasty list:

  1. Well-entrenched competitors
  2. Market changes
  3. Economic downturns (remember the dot-com bust and financial meltdown?)
  4. Personnel loss

They say 80% of all businesses fail within 5 years, and 80% of those remaining fail within the next 5.  Who’s they?  I don’t now, but my little startup is nearing year 9.  Does that make it better than 96% of the rest.  Well maybe, but I still feel like we’re just wandering in the mountains like everybody else.  🙂

–newshirt

Posted on

Why is SaaS only popular in small business?

While SaaS has been gaining popularity recently, it is remarkably noticeable that its popularity is still limited mostly to small and medium-size businesses. Larger enterprises are still reluctant to embrace hosted application for their IT needs.

According to a recent Forrester Research paper, “The Truth about Software as a Service,” which is a result of a late 2007 survey of IT decision-makers from North America and Europe, only 16 percent of respondents are using SaaS applications. On the other hand, 80 percent are still reluctant to adopt SaaS. Of the 80 percent, only 47 percent expressed interest, while 37 percent were “not interested at all.”

If SaaS has been gaining popularity recently, the gap between big-business IT decision-makers who were interested in it and those who were either partially interested or totally uninterested is too wide.  As if to counter the SaaS advantages that were cited in the previous blog, researchers and tech workers in big enterprises cite various reasons why it is not being widely adopted outside the realm of SMBs. 

One of the top reasons why big businesses are reluctant to adopt SaaS is business continuity. Put simply, the market’s atmosphere is fraught with uncertainty that SaaS vendors could just shut their doors easily. When it happens, where do the hosted data go? What alternatives are immediately available to end-users?

Next to business continuity, data security, vendor lock-in, and accountability are some of the issues that clients — both large and small or medium-size businesses — raise most of the time. Because many large enterprises are sensitive about their company data, they are reluctant to hand company information to third parties. In terms of accountability, there have been complaints about vendors’ dishonesty about real downtime rates and the speed with which they address it. If a service is suddenly cut off, IT departments ask how long it takes for the service to be available again and what kind of assurances are provided to address such issues.

SaaS are typically fit-for-all, so customization is another nagging issue. Maybe small businesses’ IT needs are not complex, that is why they are more willing to sign up with SaaS vendors. On the other hand, enterprises that provide more than one type of service, sell more than one product, are present in different locations, and employ thousands of employees have IT needs that are as complex as their multinational presence and multiple businesses. That most vendors do not offer customizable services to match big businesses’ needs is one of the signs that it is still in its infancy.

Related to downtimes is the issue of scalability. Can a hosted service support thousands of users who access the application simultaneously? If it cannot, can a business enlist the help of another vendor? This is where the issue of interoperability and portability also come in. In most cases, transferring data from one SaaS provider to another takes time and considerable effort.

That SaaS became popular among SMBs means it is promising. However, this promise does not translate well in big business so far.

By ExecutiveBrief
www.executivebrief.com

Posted on

International Project Management Day

Yes, there’s actually a “day” for project managers: November 6th, 2008.  See the link below for more information.  Here’s a little teaser quote from the web site.

http://www.internationalpmday.org/

The international project management day is intended to encourage project based organizations worldwide or organizations who utilize project management methodologies to schedule some type of recognition event within their organizations or coordinated locally with others to truly demonstrate appreciation for the achievements of project managers and their teams.

 

My job is more than just project management.  I oversee operations and projects.  I perform project planning, and do lots of project management.  I even write a little code from time to time.  My gut feeling is that most folks wear several hats these days.  Project management is only one of many.  But those many things can lead to distraction and bad projects.

An organization like this pulls us back into the discipline.  Back into the bedrock rules that make all successful projects work.  That’s a good thing.  If you haven’t registered for allPM’s webinar, here’s a link to do it!  http://www.iil.com/ipmday2008/webcast.asp

 

–newshirt

Posted on

The Pros and Cons of SaaS

Why SaaS may be the next wave in enterprise computing.

Much has been said lately about Software as a Service (SaaS), which is often interchangeably referred to as “cloud computing”. While pundits may disagree on whether SaaS is cloud computing, its primary feature is application provided as a service to customers via the internet.  Because applications are hosted, this eliminates the need for installation and running of applications on clients’ computers, or even servers, as well as maintenance and support. Moreover, SaaS reduces the need to purchase and maintain hardware.

But before getting into the much-praised or marketed trend, it is worth considering first why SaaS is such a hot commodity nowadays.  According to experts, security, maintenance, and cost are among the top reasons why SaaS is being embraced by enterprises.

Moreover, due to the challenges that face companies regarding outsourcing, such as communication gaps and security, SaaS either supplements the need of businesses to outsource parts of their IT requirements. This is especially helpful for small and medium-size businesses that do not have large IT departments, or those that can only afford to pay general IT workers instead of specialists. Because staffing has become problematic due to reduced budgets that affect tech spending, SaaS offers a way to meet their technology requirements without spending more on overhead.

Whereas the application service provider (ASP) business did not make as much mark as it should have in providing enterprise computing, SaaS is being touted as the trend that will replace and even overcome ASP.  Scaling was ASP’s main challenge, which required “separate execution environment” or different server environments for hosting different applications.  SaaS replaces multiple resources to run applications with shared computing resources, such as the same software version that runs on the same platform. This proves cheaper for end-clients.

SaaS providers offer flexible contracts that have targeted costs for specific services. Many tech projects run for only a few months, so services that provide exactly what businesses need in terms of scope and time, with corresponding costs, are advantages that SaaS vendors are only too happy to explore.

SaaS provide specialized software that increasingly meet clients’ needs. As vendors gain more knowledge about what businesses want, these insights are incorporated into version upgrades, which means better software and, just as important, more responsive service.

It is common knowledge in any industry that freeing up the need to manage back-office processes, including technology services, allows companies to concentrate on bigger, more important business areas. Perhaps at the IT level itself, this is also true. Freeing up the upkeep of some technology processes allows IT departments to focus on the services that they can provide in-house.  In effect, SaaS vendors upgrade the quality of both hosted applications and, indirectly, the quality of services of in-house IT departments.

By ExecutiveBrief
www.executivebrief.com

Posted on

9 Steps to a Hassle Free and Effective Software Development Project

Has your company developed entirely new software or added to software already in use throughout the organization and found the process cumbersome, frustrating, and sometimes not living up to expectations or meeting organizational goals?  If so, the solution to a smooth and effective development program may be as easy as staffing a well-qualified project manager and adopting a proven development process.

For any software development or other project initiative your company may be considering, it is critical to have in place and practice a set of effective and proven guidelines to ensure project success and delivery of the expected results: taking into consideration the role and responsibilities of a well-qualified project manager, knowledge of important business and financial aspects, and a step-by-step process that all contribute to the solid foundation and implementation of an effective project plan.
 

 

Developing a Practical Approach: The Role of the Project Manager

When undertaking a software development project, the first element to consider is the establishment of a comprehensive yet practical approach to the initiative that ultimately will lead to a successful end result.

The in-house project manager has a key role in ensuring each phase of the project is carried out as planned. The project manager is responsible for considering the potential risks involved with the project and how to avoid and resolve them, establishing and maintaining momentum throughout the project, ensuring individual project team member tasks are assigned appropriately and carried out according to specifications, and successfully addressing and resolving any conflicts that may arise during the length of the development project.

A well-qualified project manager is able to address what may seem to be an overwhelmingly complex process by developing an organized approach where the process is broken down into manageable individual tasks and understanding how to keep those involved in the project dedicated to the ultimate goal of meeting and even exceeding the expected end result.

Embarking on the Initiative: Key Steps to Consider

With a comprehensive approach and a competent project manager in place to guide the new software development initiative, there is another important element your organization may find helpful as you embark on the project: establishing specific steps that can be followed to project completion that are based on proven industry experience in such a project environment.

Two renowned experts, Dr. Gordon Scott Gehrs and Dr. Dorota Huizinga, single out nine key steps to consider as you embark on a software development project:

Step #1: Conduct Feasibility Analysis


Step #2: Analyze and Determine Requirements
Step #3: Consider Industry Best Practices
Step #4: Design
Step #5: Measuring and Tracking Progress
Step #6: Development
Step #7: Addressing Automation
Step #8: Testing
Step #9:  Gradual Implementation Practices
 

 

Full article, presenting in detail these key practical guidelines to approach a software development project, is available at: http://www.executivebrief.com/article/9-steps-to-a-hassle-free-and-effective-software-development-project/

 

By ExecutiveBrief: http://www.executivebrief.com

 

Posted on

A Few Reasons Why Project Changes Occur

Some of the most common reasons why change requests are made.

Change requests alter the course of a project and working within the constraints of time, budget and quality more challenging. If change requests are not handled properly, the project will overshoot its schedule and accumulate costs that are beyond the original plan.

Realize that change requests are not made because people in your team, the project sponsors, or clients cannot make up their minds. Instead, most requests for changes are made in order to improve the project and, in some cases, the process of implementing the project.

Changes are inevitable during the course of the development lifecycle, and there are various reasons why changes occur. Some of these reasons are technical, some are procedural, some are financial, and still some are political or people-related.  Whether a project manager supports the adjustments or not, it is important to think over why changes are requested and their possible impact on the integrity of the project, as well a the delivery process. Let us look at the most common reasons why changes occur.

Incomplete requirements

Scope changes –or creeping functionality–are the results of ineffective management of requirements.  These are also the results of a project manger’s inability to get approval from project sponsors. When requirements kept going through changes during the course of a development lifecycle, new features and functionalities are often added, resulting in a product that overshoots the allocated time and resources, but fails to meet an acceptable level of quality.

Organizational restructuring

If the client’s organizational structure changes midway through the project lifecycle, it is inevitable for the delivery team to expect either a closer scrutiny of the project or change requests to be submitted. Financial considerations, corporate policies, and new sets of end users are some of the factors to consider as change agents when organization restructurings happen. Some requirements are too rigid, while some requirements need more room for discrepancy in specifications.  When alpha releases prove to be too limited to one set of target users alone, then expect change requests from auxiliary end-users.

External factors, such as new vendors, technologies, or methodologies

External factors, such as the involvement of another vendor or a representative end-user, can cause diversion from the original project execution plan. This issue is often as technical as it is financial (or political). Ideas that are tied to the new vendor’s methodologies and technologies can affect the execution of the project plan halfway through the lifecycle.  Sometimes, clients can be finicky about what they want out of the project that agreed-upon requirements kept getting changed. The more a finicky client gets in contact with vendors who want to take on the project, the more ideas they get about “improving” the product and cutting the cost of development. In such a scenario, be prepared.

By ExecutiveBrief: www.executivebrief.com

 

 

 

�

Posted on

The Key Elements to Managing Projects the Virtual Way

It is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. This is about value and not just cutting costs, after all.

Advancements in telecommunication are among the key movers of offshore outsourcing. Without it, back-office operations and application development outsourcing will not be as successful as they are today.  Better infrastructure has allowed for richer applications and cheaper communication that enable businesses and their outsourcing partners to manage people and projects efficiently from different time zones.

Adopting virtualization in managing project offers great competitive advantage to companies and offshore project teams. However, with the increasingly virtualized tech industry, it is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. Remember that this is about value and not just cutting costs, after all.

To make a successful adoption of virtualization, a few key elements are involved.

Infrastructure – Both client and vendor must set up the infrastructure that can support virtualization efforts, particularly when the project at hand involves sensitive information.  Both parties need the hardware and software to host VoIP calls, and in many cases, virtual private networks (VPN).  At the start of the project, prioritize the acquisition of hardware, software, and bandwidth to support collaborative and communication efforts.

Communication Plans – Much of the success of adopting virtualization in depends heavily on communication.  On-shore project members do not have the advantages of following up colleagues whenever they want or in person. Delivery teams, on the other hand, do not have the luxury of clarifying project details immediately. In this regard, it is best to set up communication plans that define identify proper channels and approaches. Are there available people on the other end of the communication line? When should the team use virtual meetings? Is e-mail enough to update one another about the project status? Who will project members ask about issues—specific persons or entire teams? Experts agree that it is better to err on the side of over-communication.

Control and Evaluation – On top of delivering results at a time when they are expected to, offshore project teams should report plans for manpower allocations and utilization, risks and issues, and milestones.  By having these details, project teams—no matter where they are in the world—can evaluate project status and control risks. This also involves a single control system that allows for an easy generation and consolidation of data.  At the end of every period—typically weekly or monthly—such data can be measured to evaluate the success of the project in terms of quality of work, manpower and financial investment, and the lessons learned from the venture.

Collaboration Tools – A repository accessible to every member of the delivery team should be put in place. Do not rely merely on multiple copies of outputs stored in individual folders. Versioning and project management software, such as SharePoint or Perforce, allow project team members to work on single source copies of outputs, as well as archiving, checking out and backtracking of works.

By ExecutiveBrief: http://www.executivebrief.com