Posts filed under 'Project Management'
Previous Chapters
» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
Chapter V: Design
At this point in the project, detailed development plans should be made and a good foundation for coding should be in place in the form of a good design. Let’s see what happens.
With Mary not around and under pressure from Brian to get started anyway, Joe puts together preliminary versions of the formal requirements and technical design documents. Plus he and his team also develop some prototype screens to show her when she returns from her conference next week. He is unsure about the direction to take on some of it due to the rather sketchy information but he feels that having some visible choices will help her decide what’s needed and what is not really required. Fortunately, the team Brian assembled for him are competent programmers although they lack important industry knowledge.
Brian drops by with Stan and Phil in tow the following Monday and they ask how the project is going. Joe shows them the screen prototypes. After a cursory glance, Stan says, “This is great progress. We’ll have the product ready to ship in no time.” as Phil nods in agreement. Joe explains that these are simple, non-functional, storyboarded mock-ups and that he’s awaiting Mary’s further input on the design before proceeding much further. Stan and Phil look disappointed and confused while Brian’s face turns red with embarrassment and anger. Phil says, “It doesn’t look like you have much more than what Mary showed us 6 weeks ago. What’s the story here Brian?” Brian says, “I’m surprised about this too Phil but I’m going to check into it!”
After Stan and Phil leave, Brian explodes. In a huff, he pulls all the developers on Joe’s team into a meeting room. He questions the team’s competence as programmers. He calls Joe lazy and a poor leader. He finishes up by telling the team, “Stop wasting [explicative] time playing around with [explicative] fluff and just code the [explicative] program! If you can’t do it you can rest assured that I can and will find somebody who can!” 
After Joe and the team recover from their verbal beating, they start turning the rough prototypes into the actual application although there are many questions about the design remaining. Brian is happy to see that the team is coding and, a couple of days later, he tells Joe, “See what you can do if I motivate you properly.” He tells Joe not to get bogged down in the requirements and design thing. He emphasizes how important the project is and that Stan and Phil don’t want any further delays. He says that he’ll go ahead and take responsibility for signing off on the design since Mary won’t be available for at least another week since she apparently caught ‘a bug’ during her business trip.
You can bet nobody went home happy that day. In Chapter VI: Coding, we get to the heart of the work and Mary returns to the office.
Following Chapters
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
May 23rd, 2007
Previous Chapters
» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
Chapter IV: Specification and Requirement Analysis
In this phase, Joe, as the project lead, should be refining the requirements and laying out the game plan for the development to come. What happens isn’t quite that.
After the meeting with Mary, Joe has a lot of questions about her off-the-wall scribbling and the vague magazine article. He even questions the practicality of the project as he begins to analyze the information early the next week. He tries to bring this up with Brian but all he wants to know why the team, a hastily assembled group of new hires and contractors Joe didn’t even interview, isn’t coding the project yet. He tells Joe that Mary told him she had given him complete requirements just before she left and that should be all he needs. Brian says, “The requirements are in the can, done, fin-eat-oo, don’t worry about them.”
Joe starts to protest but Brian blows off Joe’s complaints about the state of the requirements again and makes it clear once again that the project has top priority. He tells Joe, “Mary is an idea person, not a detail person like you. She’s going to be out of the office for the next 10 days so why don’t you show a little initiative and write up the detailed requirements ASAP yourself? She wouldn’t know what you were talking about anyway. Take the bull by the horns and get it done! You’re a ‘can do’ kind of person, right? I only want ‘can do’ people on my team.”
Joe agrees that he is a ‘can do’ person and tells Brian that he’ll get the requirements wrapped up and hold any questions until Mary returns. Brian says, “OK, great, just get the ball rolling.”
It doesn’t look like Brian thinks much about having a lot of design work. He’s interesting in lines of code. This heats up even more in Chapter V: Design
Following Chapters
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
May 23rd, 2007
Previous Chapters
» Chapter I: Introduction
» Chapter II: Cast of Characters
Chapter III: Preliminary Investigation and Analysis
Remember, this phase should involve extracting the requirements from project sponsors and management gauging the feasibility of the the project. Let’s see what happens at our fictional mortgage software company during this step.
Mary, the Director of Marketing at EzSoftiMortgageCo, reads a trade magazine article and decides the company needs a hot new product like the one mentioned there. Does it matter that a lot of it isn’t practical or applicable to the product lines the company currently sells? Of course not! All that matters to her is that it will create some buzz at upcoming trade shows. She whips together some rough sales projection numbers and sells the idea to her boss, Stan, the VP of Sales and Marketing.
A couple of weekends later there is an executive management retreat strategy meeting. Stan and Mary give a quick presentation that relies heavily on the rough pie-in-the-sky potential sales numbers that Mary had essentially made up. Stan tells them that this is a “must have ASAP” product that has to be ready by a major trade show coming up in 6 months and preferably by the company’s national sales meeting in a little over 4 months. Phil, the CEO, is very excited about the potentially high revenue shown in the briefing. He orders Brian, the Director of Software Development, to get the project started right away.
After returning from the retreat, Brian pulls Joe, a development team lead, off the project he’s been leading for about 4 months and tells him to get with Mary about a new product ASAP. Joe protests the move by telling Brian that the current project, a key upgrade to the company’s core program suite, is nearly complete and he has the most knowledge about that complex product. Brian explains that he’s giving that project to one of the junior developers to build up their team lead experience. He tells Joe, “I want my best development lead on this new and important project. You are the best, aren’t you? That old project is on autopilot anyway, a trained monkey could handle it. Stan and Phil want this new program ASAP and are watching it closely. A high visibility project like this will give your career here quite a boost.”
When Joe tries to schedule a requirements meeting he discovers that Mary is very busy. It takes almost 2 weeks to schedule a meeting with her because she keeps canceling meetings, ignoring emails and voice messages, and is never in her office. Finally, tired of the run around, Joe asks Brian to help get a meeting set up. After complaining about Joe not taking any initiative, he grudgingly gets a meeting set up with her for about 15 minutes late on a Friday afternoon. She quickly runs through what she wants in rather general terms and then hands Joe her ideas scribbled on a couple of legal pad sheets and a poor photocopy of the article. But, more important to her, she also has images for branding the product’s splash screen and about box and a color scheme. She tells Joe, “Make sure that you use my pictures and colors in the program because that’s what I’ll be ‘sneak peak’ promoting next week at an industry conference in Jamaica next week.”
It doesn’t look like a lot of investigation and analysis was actually done in this step. Let’s see what happens when Joe starts working out the details in Chapter IV: Requirement Analysis
Following Chapters
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
May 23rd, 2007
Previous Chapters
» Chapter I: Introduction
Chapter II: The Cast of Characters
Here is the cast of characters for this fictional account of the 7 steps of software development project gone bad. As they say on TV, this story is based on actual events, the following characters are entirely fictional and any resemblance to actual persons, living or dead, is entirely coincidental and the pictures are from clip art galleries.
The Company
‘EzSoftiMortgageCo’ is a vertical market software company in the secondary mortgage industry that’s been in business for about 12 years. During that time it has seen considerable growth both in terms of revenue, nearly $100M a year now, and employees, slightly over 200. When the company began it had almost a family entrepreneurial atmosphere but the growth has led to a lot of office politics, cliques, and the implementation of questionable policies.
Company Management
Phil - The CEO – Once a top salesman for a major national bank, he struck out on his own, started the company in his basement and now runs this rapidly growing enterprise. He’s a no-nonsense, show-me-the-figures, kind of guy. He likes to stay on top of trends both in mortgage industry and in company management principles in general. He also likes to play up the “family atmosphere” of the company although it is really a thing of the past. He’s often out of touch with the day-to-day operations of the company although he likes to practice “management by walking around”.
Stan - The Vice President of Sales and Marketing – Stan has been with the company from almost the start. He likes to tell stories about how he sold the company’s first product line from the trunk of this car during cross country road trips. He was the rush chairman for his fraternity in college and his general demeanor hasn’t changed much since.
.
.
.
Mary - The Director of Marketing – She was hired 2 1/2 years ago based on her extensive industry connections and promotional skills. She’s known as being rather demanding and difficult at times but can really lay on the charm if she needs to. She is often given credit for greatly increasing the sales of the company during her tenure. Other managers in the company hold her in high regard, particularly her boss, Stan.
.
.
.
Bob - National Sales Manager – A frat brother of Stan’s, he’ll do anything to make the sale. He’s a very friendly and outgoing guy but can be rather dense at times when the subject strays from sports.
.
.
.
.
.
Information Technologies
Brian - The Director of Software Development – He has an out-going, hard-charging and often mercurial temperament. He was hired about 6 months ago due to his social connections with other company executives at a local country club. His educational and management credentials are moderately impressive but his programming experience and skills are outdated and weak. He reports directly to Phil, the CEO, since the CIO position has been vacant for almost a year. He is hoping to land this job for himself.
.
.
.
Joe - A Development Team Lead – He has a non-confrontational introverted temperament. His programming skills are considered top notch and other programmers usually like working with him although he often fails to delegate tasks well when in a lead role. He has been the Lead on 2 successful projects for the company. Joe has been with the company nearly 6 years although few people outside of IT know him well since he usually keeps to himself. He had a good working relationship with this previous boss but has not really connected with Brian, his new boss.
.
.
.
Pat - The QA Manager – She’s known for being disorganized and often difficult to deal with but she plays a good office political game. She was one of the first software developers hired by the company and the only member of the original ‘crew’ who’s still around. Because of this she has a good relationship with Phil, the CEO, and often uses this to her advantage. She was promoted to this position several years ago when it became clear that her programming skills were substandard and likely to stay that way. She technically reports to Brian but operates her department rather independently.
.
.
.
Tim - A QA Tester – This job was his first right out of college and he’s been with the company almost 2 years. He did a great job on his first few assignments but has been resting on his laurels recently. He’s a sports fanatic and has won many friends in high places in the company with his spot-on predictions and wagering advice. Pat is his boss.
.
.
.
.
Now that you know everybody, let’s begin the fiasco by moving on to Chapter III: Preliminary Investigation or Analysis, the first step in the 7 step process.
Following Chapters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
May 23rd, 2007
Chapter I: Introduction
This is the story of a software development project gone bad based around the traditional 7 steps of software development. To get things started, we will begin by reviewing these steps that many computer science courses and textbooks describe. This outline usually consists of the following:
1. Preliminary Investigation or Analysis - This is the task of extracting the requirements from users and gauging the feasibility of the project. Project sponsors usually know what they want but often have incomplete, ambiguous or contradictory requirements. It is the job of software developers and project managers to steer them in the right direction and to clarify the requirements. Upper management, both in IT and the sponsoring department, should determine if the project has business value to the organization and if there are sufficient resources to complete the project as requested.
2. Specification and Requirement Analysis - This step can vary a lot depending on the formality, size, and scope of the project and the methodology used in an organization. In general, it involves taking the requirements and describing them in a way meaningful to programmers. In your average business application this usually is a mapping between the user requirements and a description of the functionality to be coded into a program, such as a screen that displays current inventory or a report that has this month’s sales figures.
3. Design or Architecture - This step can also vary according to the project and organization. This step gets into more low level details than the previous step. For example, the specs say to develop a sales report while the design says to use VB.NET, Crystal Reports with an option to export to Excel and to query the data warehouse DB and not the main production DB.
4. Development or Coding - This is pretty obvious, this is where the rubber meets the road and the program is built.
5. Testing and Documentation - This is, of course, making sure the program functions as required and that the program’s functionality is described fully to allow for easier maintenance in the future. This is probably one of the least favorite areas among software developers.
6. Implementation or Deployment - This is process of getting the program into the hands of users. This usually includes more than just the act of distributing the software but also providing training to users.
7. Maintenance - This step is concerned with maintaining the existing program by fixing any bugs and enhancing the software. With a well written system most of the actual maintenance is for small, incremental, improvements rather than actual bug fixes.
These steps are what happen under ideal circumstances, but what happens in the real world of software development can be quite different. In this 10 part article/story, I’ll be describing a fictional development project that went wrong. It is based on my own experiences and that of other programmers. Some of it is drawn from the experiences I described in my earlier When Projects Go Wrong article.
We will begin with a look at the company and people involved
Following Chapters
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments
Share This Article:
These icons link to social bookmarking sites where readers can share and discover new web pages.
May 22nd, 2007
Next Posts
